Robert Hindel, PhD, Editor 

Implementation 

of the SliSI 
DICOM 3.0 HI 

$tanda^s||||i 

A Pragmatic 
Handbook 



RSNA. 



ltiuJ i t >1 1 *k ic a i S o c icly 
or North America 
Founded in 



Implementation 
of the DICOM 3.0 

J I A Pragmatic 

jianaara i Handbook 



Robert Hindel, PhD, Editor 



RSNA 



Radiological Society 
of North America 
Founded in 1915 



© 19% by the Radiological Society of North Amer 
2021 Spring Road, Suite 000, Oak Brook, IL 60521 



Table of Contents 



Introduction 5 
Acknowledgment 6 

Chapter 1 The Significance of the DICOM Standard 

The Role of RSNA in Supporting the Implementation 7 
and Demonstration of Dicom 3.0 

Laurens VAckerman, MD, PhD 

The Role of the Electronic Radiology Laboratory at the 10 3 
Mallinckrodt Institute of Radiology 

R. Gilbert Jost, MD 

The Role of ACR and NEMA in Supporting 12 
the Standard 

Joseph N.Gitlin,DPH 



Chapter 2 History and Essentials of DICOM 

Historic Development and Essential Features of the 16 
DICOM 3.0 Standard 

Robert Hindel, PhD 

Designing DICOM Conformance 19 

Fred Prior, PhD 

The Open Communication of Image and Related Data 29 
with the DICOM Standard 

Charles Parisot 



Chapter 3 DICOM Implementations 

The infoRAD Demonstrations 39 

Robert Hindel, PhD 

The Mallinckrodt Institute of Radiology Prototype 44 
CTN Software 

Steven M. Moore 

European CTN Implementation 48 

Andrew Hewett, PhD, and Peter Jenschr, PhD 

Chapter 4 A. Products and Vendor Strategies 



Real-World Implementation Requirements 

Robert Hindel, PhD 



50 



Example of C-Store Request 

S.M. Moore 

CTN Software in Public Domain 

Robert Hindel PhD 

B. Commercial Implementation Strategies 
Agfa's Implementation Strategy 

Carsten Weise 

Cemax Inc. 

Craig Cornelius 

Keeping Your Options Open: GE's DICOM-based 
Strategy for Building Tomorrow's Information 
Network 

Don VanSyckle and Tery Sipple-Schmidt 

The Connectivity Program of Philips Medical Systems 

Kees Smedema 

Picker International's DICOM 3.0 Commitment 

David Talton and Jay Gaeta, PhD 

Migration Path for an Existing Industrial 
PACS: SIENET 

Rainier Thieme and Christian E C. Greinacher 

Interfacing and Software Products 

Wayne T. DeJarnette f PhD 

Merge Technologies Inc. 

W Stafford 

Chapter 5 Appendices 

A. Glossary 

Robert Hindely PhD 

B. Healthcare Informatics Standards Planning Panel 

C. CEN Technical Committee 251 
List of Authors 



Introduction 



An implementation of the Digital Imaging and Communications in Medicine 
(DICOM 3.0) standard should have one primary objective: to enable reliable 
and unambiguous transfer of information objects and action definitions ("ser- 
vices") between heterogeneous systems. Such heterogeneous systems are, for 
instance, image generating systems such as CT scanners and MR imagers, stor- 
age systems such as jukeboxes and servers, image printers, and general or spe- 
cial image processing systems but also proprietary networks. They generate 
and store information objects in various formats and define actions in various 
ways. DICOM 3.0 supplies unambiguous definitions that, when used, ensure vi- 
able communication. 

This simple objective, however, is not easily accomplished. The heteroge- 
neous data formats and action definitions must be converted into the DICOM 
3.0 language either by a separate device or by software built into the heteroge- 
neous system. The infoBAD demonstrations of 1992 and 1993 have shown that 
external devices can be designed which, equipped with implementations of 
DICOM 3.0 software, can successfully communicate. Not shown and not in- 
tended to be shown was conversion of proprietary information. Commercial 
PACS installations, however, will require such conversions. 

Furthermore, a real-world implementation will deal with several participat- 
ing nodes called Application Entities (AEs). The Conformance Statement of 
the standard can be used as a blueprint for system compatibility. 

The five chapters are organized in a logical sequence: 



Chapter 1 contains statements by key promoters of the standard. 

Chapter 2 gives a brief history and explains the essentials of the 
DICOM 3.0 standard. 

Chapter 3 describes the infoRAD demonstrations as important coopera- 
tive projects. 

Chapter 4 lists available products in terms of software, hardware and 

support. It also supplies the reader with statements by major 
vendors in the PACS market as to their particular approach 
and strategy for DICOM 3.0 implementation. 

Chapter 5 contains supplementary information such as a glossary and 
comments about related developments. 



This handbook does not introduce the reader to the intricacies of the stan- 
dard, but rather addresses topics that the standard deliberately excludes, 
namely, conversion of inputs, specific implementation strategies, and integra- 
tion of many conformant AEs on a network. 



Acknowledgments 



Many have contributed either by supplying written portions to the manuscript or offering advise 
and general support. As editor, I should like to express my thanks and appreciation to: 

Ackerman L. V, MD, PhD, RPSLMC, Chicago 
g Chairman, Electronic Communications Committee, RSNA 

Best D., Kodak, Co-Chairman, ACR-NEMA Standards Committee 
Bennet W, Kodak, past Chairman, WG VI 

Blaine G. J., DSc, Director, Electronic Radiology Laboratory, Mallinckrodt Institute 

of Radiology 
Britain R. G., Vice President, NEMA 

Cornelius C, Cemax Inc., Director, New Business Development 

DeJarnette W, PhD, President, Dejarnette Research Systems 

Drew S., Assistant Executive Director for Informatics and Scientific Assembly, RSNA 

Gaeta J., PhD, Picker International 

Gitlin J.N., DPH JHU, Chairman, RISC, and Chairman, NEMA MedPacs Section 
Gray M, J., Gray Consulting 

Greinacher C, Dr Ing, Dipl Phys. Siemens, Germany (retired) 

Heu R., Group Manager, Philips Medical Systems, Germany 

Hewett A., PhD, Informatics, University of Oldenburg 

Jensch E, Professor of Informatics and PhD, University of Oldenburg 

Jost R. G., MD, Professor and Chief, Diagnostic Radiology, Mallinckrodt 

Institute of Radiology, St. Louis 
Moore S.M., Team Leader ERL, Mallinckrodt Institute of Radiology 
Mortimer W, President, Merge Technologies Inc. 
Parisot C, GE France, principal author, part VIII, DICOM 3.0 
Primo H., Intern. Manager, Marketing and Applications, Agfa Belgium 
Prior E, PhD, Assistant Professor, Penn State University, key contributor to several parts 

of the DICOM 3.0 standard 
Rowberg A., MD, University of Washington, Seattle 
Schmidt T, GE Medical Systems 

Smedema C, Corporate Technology, Philips, The Netherlands 
Smith D., Director, CT Eng., Picker International 
Snavely D., Staff Executive, NEMA 

Stafford W, Vice President, Sales and Service, Merge Technologies Inc. 

lalton D., Picker International 

Tesche G., Philips Medical Systems, Germany 

Thieme R., Dipl. Phys., Siemens Germany 

VanSyckle D., GE Medical Systems, Chairman, WG VI 

Weise C, AGFA Belgium 

Wolfe B., consultant to RSNA 

Robert Hindel, PhD 



CHAPTER 1 

The Significance 
of the DICOM 
Standard 



As you read this handbook, it will be obvious that the 
setting of the Digital Imaging and Communications in 
Medicine (DICOM) 3.0 standard, its implementation, 
demonstration, and final acceptance has been a long pro- 
cess involving a considerable amount of financial and 
time commitments from a large group of individuals and 
organizations. This year, the standard and implementa- 
tion have matured to early adulthood, able to stand by it- 
self as it emerges into the medical imaging world. Dr. 
Jost provides a good history of the implementation pro- 
cess of the standard in the early 1990s in his chapter 
"The Role of the Electronic Radiology Laboratory at the 
Mallinckrodt Institute of Radiology." 

As Dr. Jost notes, the RSNA Electronic Communica- 
tions Committee (ECC) started to work with the Ameri- 
can College of Radiology-National Electronics Manu- 
facturers Association (ACR-NEMA) MedPacs ad hoc 
section for demonstration of the DICOM standard early 
in 1992. An RFP was formulated for the software imple- 
mentation of a limited demonstration and circulated by 
the RSNA, and the Electronic Radiology Laboratory 
(ERL) at the Mallinckrodt Institute of Radiology was 
selected. With the approval of the RSNA Board of Di- 
rectors, the RSNA decided to initially fund the project 
with the hope that part of the funding would come later 
from participating organizations. The first year's dem- 
onstration at the RSNA scientific assembly and annual 
meeting in November 1992 consisted of (a) a local net- 
work of Sun computers that supported the central test 
nodes connected to the participating vendors by means 
of a Cisco router and (6) a local network set up in the 
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infoRAD demonstration area. A considerable amount of 
work was put forth by the ERL in a very short time to cre- 
ate the first set of software for RSNA '92. The ERL was 
able to write the software, put together extensive documen- 
tation, and hold a users' conference in about 3 months with 
a simple but robust set of software that functioned with 
very few errors at the first DICOM 3.0 demonstration. 

In 1993, Mallinckrodt Institute of Radiology was again 
selected by RSNA to write a more sophisticated set of soft- 
ware for the RSNA meeting in November. At that meeting, 
however, a considerable change was to take place as the 
ECC decided that all of McCormick Place in Chicago 
should be networked to help in the demonstration of the 
standard. RSNA established the Network Operation Cen- 
ter, which consisted of about 20 full-time people and appro- 
priate computer equipment, to support the network. Two 
networks were constructed. The DICOM network was set 
up to allow anyone in McCormick Place to participate in the 
demonstration, but the network was closed to communica- 
tion from outside McCormick Place. Another parallel net- 
work was constructed and was connected to the Internet 
through a T3 connection. Both networks provided 10-Mbit 
Ethernet and 100-Mbit FDDI connections. It should be 
noted that the network setup was accomplished in under 1 
week and was the size of, or larger than, that presently in 
the largest hospital setting. This was accomplished by as- 
sembling the wiring, routers, hubs, bridges, and supporting 
computer systems in a test setting well before the Novem- 
ber meeting. Again, the demonstration was very successful. 

At the end of RSNA '93, the DICOM 3.0 software was 
adjusted for software errors found at the meeting and, as 
of January 31, 1994, was placed on the RSNA and 
Mallinckrodt ftp servers and made available through 
anonymous ftp, open to all on the Internet. It was also 
made available, for media costs, on magnetic tape to those 
who did not have Internet connections. It was felt at that 
time that the standard and implementation were robust 
enough to be used in a commercial setting and that, by re- 
leasing the software for free, DICOM would rapidly grow. 



Also, because there was one publicly available set of source 
software, we felt that communication between different 
systems would be easier if there were one freely available 
DICOM 3.0 software implementation. This has proven to be 
the case, as evidenced by the mention of DICOM both in 
articles and, more importantly, in advertisements in many 
radiology journals. 

For a third year, the RSNA has contracted with 
Mallinckrodt Institute of Radiology to help with the demon- 
stration of the DICOM 3.0 standard. This year, the RSNA 
has constructed one large network for all functions at the 
meeting, the majority of which will serve the DICOM dem- 
onstration. The initial testing of whether an organization 
can connect to the meeting will be performed, not in a large 
"connectathon" prior to RSNA '94, but over the Internet. 
We hope that this year DICOM will become an essential, 
though routine, part of our meeting. 

In sum, over the past 3 years, the RSNA's November 
meeting has become a laboratory for DICOM 3.0, bringing 
the standard developed by ACR-NEMA into implementa- 
tion and acceptance by the world of radiology and other ar- 
eas of medicine. This has been made possible through the 
financial support of the RSNA and participating commer- 
cial vendors, the code developed by ERL, and the coopera- 
tion and support of many other individuals and organiza- 
tions. In the future, we see the RSNA scientific assembly 
and annual meeting as a laboratory that will foster connec- 
tivity with DICOM as the first in a line of successful experi- 
ments. 
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For over 10 years, countless devoted individuals have con- 
tributed effort and energy toward the development of a 
standard for storage and transmission of radiologic images. 
This effort, known as the ACR-NEMA standardization 
project, has faced its share of difficulties in gaining accep- 
tance. A turning point came in the early 1990s, when some 
major innovations were introduced. First, a revision of the 
standard called for the use of networks based on TCP/IP 
and OSI implementations instead of relying on a physical 
connection through a unique fifty-pin plug. At about the 
same time, an important new version of the standard, now 
known as DICOM version 3.0, was introduced along with 
significantly enhanced functionality. 

In response to these developments, the MedPacs section 
of NEMA chaired by Dr. Robert Hindel proposed a demon- 
stration, of the standard to promote its acceptance. An ad 
hoc committee was charged with setting up ground rules 
for the demonstration. In an innovative development, the 
committee decided that vendors would not communicate 
with one another directly but would exchange images 
through a central exchange point known as a central test 
node (CTN). The vendors were to communicate with the 
CTN through their own demonstration prototype node 
(DPN). Instead of requiring vendors to exchange images di- 
rectly, vendors could exchange images via the CTN. This 
permitted a robust demonstration of the standard without 
requiring prearrangements among the participating compa- 
nies. 

The MedPacs section, in order to facilitate the demon- 
stration turned to Dr. Laurens V Ackerman, who is now 
chairman of the Electronic Communication Committee of 
the Radiological Society of North America (RSNA). To- 
gether they realized that the development of a common 
software layer was important to a successful demonstration 
of the standard, and on April 11, 1992, they called for pro- 
posals from universities to develop the software. About a 
month later, the committee selected the Electronic Radiol- 
ogy Laboratory at the Mallinckrodt Institute of Radiology 
to pursue the development. 



A flurry of activities ensued during the next 2 months as 
a development team was assembled under the direction of 
Steve Moore and the software was prepared. On July 1, 
1992, twenty-five vendors agreed to participate in the dem- 
onstration at RSNA '92, and on July 15, a workshop was 
held in St. Louis to describe the software and distribute 
code. More than 300 pages of documentation and over 
28,000 lines of code were distributed to the participants at 
this time. 

Throughout the process, a number of groups including 
RSNA, ACR, NEMA, and RISC provided substantial sup- 
port to the effort. During the week of September 14, 1992, 
an evaluation and validation session was arranged in Chi- 
cago for each of the vendor participants in order to work 
out all of the many anticipated difficulties. Although a week 
was set aside for this process, everyone was surprised to 
find that all of the vendors were successfully communicat- 
ing using the DICOM protocols during the first day of the 
trial. 

At RSNA '92, a highly successful demonstration took 
place in a large venue that was the focal point of the 
infoRAD exhibit. Most of those who saw and participated 
in the demonstration recognized that it represented an im- 
portant step forward in the public recognition of the value 
and importance of an imaging standard. 

The success of the 1992 demonstration provided a foun- 
dation for a more elaborate demonstration in 1993 and 
Mallinckrodt was again asked to develop software, this 
time with substantially enhanced functionality that incorpo- 
rated HIS/RIS connectivity This software was subse- 
quently placed into public domain. Even more ambitious 
plans are called for in 1994 and 1995, when true inter- 
connectivity among vendors and academic participants at 
the annual RSNA scientific assembly will be realized 
throughout the entire meeting. 

I am proud of the efforts of the Electronic Radiology 
Laboratory but am quick to recognize that this is only a 
very small element of an effort that has been carried for- 
ward on a number of fronts for many years by a host of de- 



voted individuals and organizations. DICOM has finally 
reached a high level of acceptance. The public demonstra- 
tions have served to prove the feasibility of the process, and 
industry is now investing seriously in the realization of a 
method for true intervendor connectivity. Most agree that 
this long-awaited standard will facilitate the vigorous 
growth of digital image management, which, in turn, will 
transform the way we practice radiology in the years ahead. 
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The approval of DICOM 3.0 for publication and the demon- 
stration of implementations as commercially available prod- 
ucts at RSNA '94 are important milestones in the continuing 
development of the standard. These milestones represent 
the successful accomplishment of the major goals adopted 
by the American College of Radiology (ACR) and the Na- 
tional Electronics Manufacturers Association (NEMA) 
when the joint effort was defined in 1983. After more than 
10 years of intensive effort by both the ACR, which repre- 
sents the principal users of imaging equipment, and NEMA, 
which represents the major suppliers, the network version 
of the standard is available. It is anticipated that this version 
will be formally adopted as a national and international stan- 
dard in 1995, after submittal to the appropriate governing 
agencies in Japan, Europe, and North America. 

The demonstrations of the standard at RSNA '94 will in- 
clude the public domain implementation developed at the 
Mallinckrodt Institute of Radiology with support from 
RSNA, and commercially available interpretations by more 
than 40 companies that will be linked to RSNAnet at the an- 
nual meeting. The large number of products that comply 
with the standard should facilitate the utilization of digital 
image management systems and picture archiving and com- 
munication systems (PACS) by hospitals and other health 
care organizations. The demonstration at this time is par- 
ticularly appropriate in view of the emphasis on advances in 
medical imaging associated with the 1995 centennial cel- 
ebration of Roentgen's discovery of x rays. 



The impetus for the development of the standard was 
the recognition of the value of digital imaging devices such 
as computed tomography (CT) (known as computerized 
axial tomography in the 1970s) in the diagnosis of a wide va- 
riety of diseases and injuries. The immediate clinical accep- 
tance of CT and the availability of other digital imaging mo- 
dalities such as nuclear medicine, ultrasound, and magnetic 
resonance imaging generated the perceived need for inte- 
grated electronic systems that could accommodate all types 
of imaging equipment produced by different manufactur- 
ers. This, in turn, led to the recognition that a standard was 
required to ensure effective communication among the im- 
aging devices and related computer equipment 

While the need for an interface standard was long recog- 
nized, effective action to create the standard did not occur 
until 1983, when members of the ACR combined efforts 
with representatives of manufacturers through the newly 
formed ACR-NEMA Standards Committee. This commit- 
tee, through joint action, was extraordinarily effective. In 
just 2 years, the committee and its working groups created 
an industry-standard interface originally known as the 
ACR-NEMA Digital Imaging and Communications in 
Medicine (DICOM) standard (defined in NEMA publication 
no. 300-1985). By the RSNA annual meeting in 1987, most 
manufacturers had included the ACR-NEMA standard in 
their lists of equipment specifications (1). 

The ACR presented the needs and rationale for the ef- 
fort, while NEMA committed itself to resolve the technical 
issues that faced the industry A joint committee composed 
of radiologists and experts from industry was formed to ad- 
dress the issues of compatibility involved in the interface of 
various digital imaging modalities. Over the next 2 years, 
working groups met, shared information, and developed the 
hardware specifications, defined the data elements needed 
in a message, and established goals for system performance 
and function (2). 

The ACR-NEMA standard interface allows digital medi- 
cal images and related information to be communicated be- 
tween imaging devices, regardless of manufacturer or im- 



age format. Development of this interface was believed to 
be the first step necessary in the development of standards 
for PACS. Without data exchange, the backbone of digital 
image communication and storage, other efforts to encour- 
age the development of PACS would fail. 

At the first PACS meeting (held in 1982), the problem of 
acquiring images and related data from different manufac- 
turers' equipment was already apparent. The desire to ac- 
quire digital data in a direct manner was strong, but ven- 
dors were cautious about revealing how their software 
worked. The potential users of PACS, namely the radiology 
community, asked the ACR to help find a solution. Engi- 
neering experts among the manufacturers also began to re- 
alize that little would be gained by keeping image formats 
proprietary. The result was the formation of the ACR- 
NEMA Digital Imaging and Communications Standards 
Committee early in 1983 (3). 

After 2 years of work, the first version of the standard, 
ACR-NEMA 300-1985 (also called ACR-NEMA version 
1.0), was published and distributed at the RSNA annual 
meeting in 1985. As with many first versions, errors were 
found, and improved ways of doing things were suggested. 
In response, the committee began working on changes to 
improve the standard. In 1988, ACR-NEMA 300-1988 (or 
ACR-NEMA version 2) was published. It used substantially 
the same hardware specification as version 1 but added new 
data elements and fixed a number of errors and inconsis- 
tencies. 

By 1988, many users recognized that an efficient inter- 
face between imaging devices and a network was required. 
While this could be done with version 2, the standard lacked 
the parts necessary for robust network communication, and 
a solution to these problems meant that major changes 
would have to be made to the standard with the constraint 
of retaining compatibility with earlier versions. 

The ACR-NEMA DICOM standard has gained recogni- 
tion by manufacturers and users as a significant factor in 
the future of medical imaging. It must be remembered that 
because the standard is not mandatory, its implementation 



by equipment suppliers is optional. Support for the stan- 
dard has grown with migration from the "black-box" to an 
integrated interface (4). The standard is seen as a dynamic 
development, being changed and improved in response to 
the needs of the medical community with the support of the 
manufacturers. A goal of the committee is to make future 
versions of the standard compatible with previous versions 
and, whenever possible, develop new versions that can be 
"understood" by existing implementations. 

It is anticipated that ACR and NEMA will continue to 
support further development of the standard and that col- 
laboration with other medical disciplines and international 
agencies will enhance its utility around the world. Although 
much remains to be done, a great deal of credit is due the 
individuals and organizations that have contributed to the 
progress to date. Roentgen's centennial year should see 
formal adoption of version 3.0 and the establishment of an 
international "consortium" that will have the responsibility 
and resources to continue the dynamic process of develop- 
ing future versions of the standard. These efforts often 
seem far removed from the delivery of care to patients, but 
if medical imaging technology is to continue its contribu- 
tions to cost-effective diagnosis and treatment, an evolving 
standard is an essential component. 
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The DICOM 3.0 standard evolved from earlier versions 
called ACR-NEMA standards version 1.0 (1985) and version 
2.0 (1988) (1,2). The essential demand for a digital imaging 
standard arose in the early 1980s from the frustration of 
ACR representatives with the inaccessibility of digital im- 
age data produced by CT scanners and MR imagers. These 
data were stored on magnetic tapes and flexible disks (flop- 
pies) but could not readily be deciphered by the customers. 
The single most significant demand from ACR was that 
NEMA, as industry representative, should cooperate in 
forming a standards committee charged with addressing 
this issue. Three working groups (WGs) were formed, each 
reporting to the ACR-NEMA standards committee, which 
was headed jointly by an ACR representative and a NEMA 
representative. The original WGs were 



WGI 
WGII 
WG III 

New WGs are 

WGIV 
WGV 
WGVI 
WGVII 
WG VIII 



Hardware and Protocols 
Data Groups 
System Performance 
Specifications 



Data Compression 
Exchange Media 
Validation (and Upgrades) 
Multidimensional Data 
HIS/RIS/PACS Interface 



Other new WGs have since been proposed. 

Now, 9 years later, the definition of images is still the 
most important information, although it occupies only a 
fraction of the bulk contained in the 10 parts of DICOM 3.0 
Standard (3). These are 



Parti 
Part 2 
Part 3 
Part 4 
Parts 
Part 6 
Part 7 
Part 8 
Part 9 
Part 10 



Introduction and Overview 
Conformance 

Information Object Definitions 
Service Class Specifications 
Data Structure and Semantics 
Data Dictionary 
Message Exchange 
Network Communication 
Point-to-Point Communication 
Media Storage and File Format 



Diagnostic images, particularly series of CX MR, and ul- 
trasound images, may be 100 MByte (100 million bytes) or 
larger. Sophisticated technology is needed in order to fetch 
these images fast from storage and present them conve- 
niently to the radiologist. A fast network is needed if these 
images are remotely stored. By contrast, all other clinical 
and demographic information can be expressed by less than 
0.1% of the data quantity needed for images. Robust, reli- 
able, and affordable technology exists that can handle such 
quantities. PVirthermore, well-established radiology infor- 
mation systems (RIS) and hospital information systems 
(HIS) exist and provide information and department man- 
agement functions. 

In response to the published version 2.0 of the ACR- 
NEMA standard, users requested a network version. It 
also became evident that medical informatics should be ad- 
dressed on a broader basis. The developments in Europe 
initiated by the Comite Europ6en de Normalisation (CEN) 
through its Technical Committee 251 (TC 251) required a 
matching design. A crucial requirement was adherence to 
language and structure of OSI. (More information about 
TC 251 is available in Appendix C.) 

In 1991, NEMA joined HISPI? the ANSI Healthcare In- 
formation Standards Planning Panel, which coordinates ef- 
forts toward a comprehensive healthcare informatics stan- 
dard in the United States. (More information on this topic 
is available in Appendix B.) 

Therefore, the ACR-NEMA standard, version 2.0 was 



rewritten in order to become conformant with ISO and 
OSI. 

THE CONCEPT OF AN 
OPEN SYSTEM 

The DICOM standard is patterned after OSI, the Open 
System Interconnection of ISO. The key feature of OSI is 
communication between heterogeneous systems. It was 
developed as a generalized model based on the experience 
with ARPANET and CYCLADES (4). "Openness" is estab- 
lished when participating parties agree on a communication 
protocol. The "message" that is transmitted between the 
communicating partners ("nodes") is expressed in a speci- 
fied form. The DICOM standard specifies this form through 
the tranfer syntax that defines the coding of the informa- 
tion. The message itself is accompanied by instruction ele- 
ments appropriate to the communication channel (for in- 
stance, which communication "stack" will be used). 

A nontechnical parallel would be a communication be- 
tween two mathematicians with no common conventional 
language, in which one asks a question by means of symbols, 
and the other replies by means of symbols. They would use 
mathematical coding as a common language. Alternatively, 
they could each find a translator who speaks a common con- 
ventional language. This would require double translation in 
each direction; faulty "coding" (misunderstandings) would 
probably occur. 

Aside from the enormous amount of detail and complexity 
of the OSI standard, the essential feature of the standard is 
the transportable message in well-defined form, the capabil- 
ity of the sending node to generate this message, and the 
corresponding capability of the receiving node to decipher 
or parse this message. The sending and receiving nodes 
need not use the same operating system or the same appli- 
cation program. They can be, and in many cases will be, het- 
erogeneous. 

Internet, which evolved from ARPANET) is an example of 
such an open communication system (5). According to some 
sources, it connects more than 2 million computers and ac- 



commodates more than 15 million users. It offers greater 
functionality than DICOM but simpler coding. 
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1. INTRODUCTION 

A standard is an agreement that establishes a framework 
within which to solve a class of problems. It is meant to fa- 
cilitate consistent implementations by building an abstract 
model of a class of solutions. A standard is not an implemen- 
tation specification. It cannot guarantee interoperability of 
implementations. 

The DICOM standard includes a broad selection of ser- 
vices and a variety of options. Any implementation will logi- 
cally select a subset of functions and optional elements. For 
interoperability it is essential that these choices be made 
consistently. The standard provides a mandatory mecha- 
nism whereby implementors can define precisely the sub- 
set of DICOM features and functions that comprise a par- 
ticular implementation. 

NEMA publication PS 3.2-19931 (1) specifies that all 
implementations must be accompanied by a properly struc- 
tured Conformance Statement. A Conformance Statement 
is a formal compilation of the exact set of DICOM func- 
tions, services, and options that are included in a particular 
implementation. The Conformance Statement must indi- 
cate how the implementation meets the conformance re- 
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quirements specified in all other parts of the DICOM stan- 
dard. 

Conformance to a standard means compliance to the re- 
quirements of the standard. Conformance does not mean 
validation. Conformance does not imply a mandate for a par- 
ticular implementation. The purpose of a Conformance 
Statement is to allow a user to determine which optional 
components of the DICOM standard are supported by a par- 
ticular implementation and what extensions or specializa- 
tions an implementation adds. By comparing the Conform- 
ance Statements from two implementations, a knowledge- 
able user should be able to determine whether or not 
interoperability is possible. If the Conformance Statements 
are complimentary, and the vendor's implementations are 
adequately and accurately described by these statements, 
the probability of interoperability is greatly increased. 

How should a user specify DICOM conformance? History 
has shown that simply writing a request for proposal or pur- 
chase agreement requiring "ACR-NEMA" or "DICOM" is 
not sufficient. The user community needs to understand the 
conformance specification process and to clearly articulate 
DICOM conformance requirements (2). It is also incumbent 
upon the user community to police the market and call into 
question marketing claims that are not backed by a properly 
constructed conformance statement. The Conformance 
Statement must become a key customer requirement levied 
on all vendors. 

It has been observed by several implementors that the 
best way to grasp the requirements of the DICOM standard 
is to carefully study the conformance document (1). This is 
not surprising, since the goal of any implementation is to 
solve a problem in a way that conforms to the requirements 
of the standard. The following sections will explore the 
structure of a DICOM Conformance Statement and how it 
may be used as a road map to the standard. 

2. STRUCTURE OF A CONFORMANCE STATEMENT 

NEMA publication PS 3.2-1993 defines the requirements for 
creating a Conformance Statement. Annex A of this docu- 



ment is a detailed outline of an arbitrary Conformance 
Statement. Annex B provides an example of a Conformance 
Statement based on two fictional applications: DIS and DAT 
Van Syckle et al (3) describe a more concrete example based 
on an actual implementation. It is crucial to note that PS 3.2 
only specifies requirements for the creation of a Conform- 
ance Statement. The actual conformance requirements to 
which implementations must comply are specified in the re- 
maining parts of the standard (NEMA publications: PS 3.3 - 
PS 3.10). 

A DICOM Conformance Statement that describes an ac- 
tual implementation does not have to exactly follow the for- 
mat defined in PS 3.2 Annex A. It does, however, have to in- 
clude a comprehensive description of the implementation. 
Figure 1 is a pseudocode representation of the Conform- 
ance Statement generation algorithm defined by Annex A. 
The reader will note several conditional statements and 
reasonably complex looping structures (indicated by "For" 
and "End For"). 

The initial section of a Conformance Statement must 
identify the domain of application of the implementation. 
This is done by clearly stating the problem set being ad- 
dressed (e.g., transferring images from a CT scanner to a 
storage device) and by a data-flow diagram that relates the 
implemented functionality to real-world activities. At this 
highest level of abstraction, the Conformance Statement 
deals with activities and events in the real world and identi- 
fies application entities (AEs) that implement DICOM 
functions relevant to the identified activities. 

A DICOM AE is a named package of DICOM services 
that may be separately addressed on a network. Most 
likely, an AE is a software process running on a host pro- 
cessor. An AE uses DICOM services to implement a subset 
of the application layer functionality defined by the DICOM 
standard. Any DICOM implementation will comprise one 
or more AEs. The goal of a Conformance Statement is to 
completely specify the functionality and constituent compo- 
nents of these AEs. As illustrated by Figure 1, the bulk of a 
Conformance Statement is taken up by AE specifications. 



An application data-flow diagram is an important tool to 
graphically illustrate the domain of interest of the imple- 
mentation, how the implementation is partitioned into AEs 
and how real-world activities relate to the supported 
DICOM functions. Figure 2 is an example of a data-flow 
diagram of the type proposed in Annex A. Although initially 
created as part of a user conformance document rather 
than a conformance statement, it illustrates the basic con- 
cepts and content of such a diagram. The diagram repre- 
sents a generic modality interface that supports a means to 
communicate (a) patient and study identification informa- 
tion from an information system (HIS/RIS/PACS) to an im- 
aging modality and (b) images and study component infor- 
mation from the modality back to storage and information 
management systems. 

By DICOM convention, an application data-flow dia- 
gram uses rectangles to illustrate AEs and circles for real- 
world activities. The model is divided into two segments: in- 
ternal to the implementation environment being described 
and external. Single-headed arrows are used to indicate the 
direction of association establishment (the arrowhead 
points away from the association initiator) and double- 
headed arrows to indicate the relationship between internal 
triggering events and actions across the DICOM interface 
boundary. In the example in Figure 2, two AEs have been 
identified: a study management (SM) AE and an image 
management (IM) AE. The SM AE receives association re- 
quests from a DICOM service class provider wishing to 
communicate information about a study scheduled event 
(one of the event types specified in PS 3.4 as part of the De- 
tached Study Management Service Class specification). The 
SM AE initiates associations to a DICOM service class pro- 
viders to get patient information, create study components, 
and update study component information. The IM AE ini- 
tiates associations to store images to a service class pro- 
vider of the appropriate storage service object pair (SOP) 
class. 

Once the functional scope of the conformance statement 
has been articulated and a set of AEs identified, focus shifts 



AE Specifications 
For each AE 

If this AE initiates Associations Specify Association establishment policies 
For each Real-World Activity that results in Association initiation 
Specify associated Real-World Activity 

Specify proposed Presentation Contexts 

For each Presentation Context 

Specify SOP Specific Conformance 

End For 

End For 

End If 

If this AE accepts Associations 

Specify Association acceptance Policies 

For each Real-World Activity that results in Association acceptance 
Specify associated Real-World Activity 

Specify acceptable Presentation Contexts 

For each Presentation Context 

Specify SOP Specific Conformance 

End For 

Specify Presentation Context acceptance criteria 
Specify Transfer Syntax selection policies 

End For 
End If 
End For 



Figure 1. How to 
construct g DICOM 
Conformance State- 
ment with an imple- 
mentation model. 
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Communication Profiles 



For each supported OSI stack 

Specify International Standardized Profile (ISP) 
End For 

If the TCP/IP Stack is supported 

Specify TCP/IP support 
End If 

If Point-to-Point Stack is supported 

Specify Point-to-Point support 
End If 

If the product claiming conformance is a tool kit 
Specify an Application Programming Interface 
End If 

Specify physical media support 

Extensions/Specializations/Privatizations 

If any extensions to the standard were referenced in AE Specifications 
For each Standard Extended/Specialized/Private SOP 

Specify the Standard Extended/Specialized/Private SOP 

End For 

End If 

If any Private Transfer Syntaxes were referenced in AE Specifications 
For each Private Transfer Syntax 

Specify the Private Transfer Syntax 

End For 
End If 



Configuration 

Support of Extended Character Sets 




to a much lower level of abstraction. The behavior of each 
AE must be described in detail. 

3. APPLICATION ENTITY SPECIFICATIONS 

A complete specification must be provided for each AE en- 
compassed by the Conformance Statement. The specifica- 
tion must enumerate the functions performed by the AE 
and the DICOM services that are used. A summary list of 
SOP classes to which the AE conforms should be provided. 

An SOP class is the atomic unit of conformance. A SOP 
class UID uniquely specifies a set of DICOM message ser- 
vice elements (DIMSE) and a DICOM information object 
definition (IOD) plus additional application specific seman- 
tics (as defined in the service class specification to which 
the SOP class belongs). The SOP class UID plays a second 
role in DICOM. Because they each identify a well-defined 
unit of DICOM functionality, SOP class UIDs are used as 
the Abstract syntax name component of a presentation con- 
text. It is, therefore, the SOP class that is negotiated dur- 
ing Association establishment. 

For each real world activity identified in the data-flow 
diagram (Fig 2), the AE specification must indicate whether 



Presentation Context Table 


Abstract Syntax 


Transfer Syntax 


Role 


Ext. Neg. 


Name 


UID 


Name List 


UID List 






CT Image 
Storage 


1.2.840. 100085.1.4 
1.1.2 


DICOM 
impl. 
WLit 
End. 

DICOM 
expl. 
VRBig 
End. 


1.2.840. 10008.1.2 
1.2.840.10008.1.2.2 


SCU 


none 


CRA Image 
Storage 


1.2.840.10008.5.1.4 
1.1.2 


DICOM 
impl. 
VRLit. 
End 

DICOM 
expl. 
VRBig 
End. 


1.2.840.1008.1.2 


SCU 


none 



Figure 3. Example of a presentation context table. 



the AE initiates or accepts associations and describe any 
implementation specific behaviors. For each association it is 
necessary to identify the set of acceptable presentation con- 
texts. A table such as the example illustrated in Figure 3 
should be included. Such tables summarize a great deal of 
information, including acceptable abstract and transfer 
syntaxes, whether the AE acts as a service class user 
(SCU) or service class provider (SCP) of the indicated SOP 
class, and whether SOP specific extended negotiation is 
supported. 

It the AE accepts associations, the Conformance State- 
ment must indicate the criteria and priority for choosing 
presentation contexts when multiple are supported. Simi- 
larly, if the AE can support multiple transfer syntaxes 
within a given presentation context, the policies and priori- 
ties governing syntax selection must be specified. 



4. COMMUNICATION PROFILES AND 
CONFIGURATION 

DICOM is a communication standard. Logically, one would 
expect the bulk of the standard to be devoted to the specifi- 
cation of communication protocols at each of the seven lay- 
ers of the ISO Open Systems Interconnect (OSI) reference 
model 4. In fact, the DICOM standard deals almost exclu- 
sively with the seventh (application) layer of the OSI model 
Only NEMA publications PS 3.8 and PS 3.9 actually address 
the lower six layers. 

DICOM applications are defined to function over three 
distinct classes of lower-layer protocol stacks: ISO, TCP/II? 
and the DICOM point-to-point protocol. A conforming 
implementation may choose to support one or more of these 
protocols. In all cases, significant details of the chosen stack 
must be communicated. For example, DICOM does not 
specify a specific ISO international standard profile (ISP) 
but rather permits the implementor to select from several 
possible known ISPs (e.g., US GOSIP [7]). Clearly it is im- 
portant for interoperability for this selection to be indicated 
in the Conformance Statement. 

The DICOM standard permits a number of media access 
layer protocols and physical media. The Conformance state- 
ment must indicate which protocols (e.g., FDDI, Ethernet, 
orlSDN) are supported and over which media (fiber, coaxial 
cable, twisted pair, etc.). Each of the possible media re- 
quires specific transceivers and connectors. Anyone who 
wishes to determine the interoperability of two implemen- 
tations needs a clear understanding of the supported proto- 
cols and physical media options they support. DICOM over 
FDDI and DICOM over primary-rate ISDN are both valid 
implementations but are not directly interoperable. 

Each implementation will logically include a number of 
configurable parameters. At a minimum, a mechanism for 
mapping AE titles (logical addresses) into presentation ad- 
dresses (or in the TCP/IP world, IP addresses) must be 
provided. The standard requires this but does not specify 
the mechanism. It is important to define in a Conformance 
Statement how this task is accomplished. Similarly, if the 



implementation includes an SCP that invokes the DIMSE N- 
Event-Report service, it is necessary to specify the mecha- 
nism the AE will use to determine the list of AE Titles to 
which event reports are to be sent. Finally, permitted values 
of configurable parameters such as time-out thresholds 
should be specified. 

5. EXTENDING THE STANDARD 

The DICOM standard includes provisions for an implementor 
to extend the currently defined functionality of the standard. 
These provisions were included to permit experimentation 
with new techniques and even new imaging modalities that 
are not yet covered by the standard. If an implementation 
employs one of the extension techniques, and the imple- 
mentor wishes to make the extensions public, the Conform- 
ance Statement must include a complete specification of the 
extension. 

Three basic mechanisms are provided to extend the 
DICOM standard: standard extended SOP classes, special- 
ized SOP classes and private SOP classes. A standard ex- 
tended SOP class is a slight variation on one of the SOP 
classes defined in PS 3.4. In must meet all of the require- 
ments for the standard SOP class upon which it is based and 
only include additional optional (type 3) attributes. These at- 
tributes may be either public attributes defined in the 
DICOM data dictionary or private attributes defined by the 
implementor (equivalent to ACR-NEMA version 2.0 "shadow 
elements") (8). A standard extended SOP class uses the same 
unique identifier (SOP class UID) as the standard SOP class 
upon which it is based. A specialized SOP class is also based 
on a standard SOP but it may contain additional attributes 
(either public or private) that are mandatory. Because this 
introduces new semantics, a specialized SOP class must be 
identified with a user-specified SOP class UID. A Private 
SOP class introduces completely new functionality and is not 
necessarily based on any existing DICOM-defined SOP It 
may contain public and private attributes. The implementor 
is only restricted in that no new DIMSE services may be uti- 
lized in a private SOP class. 



If specialized or private SOP classes are defined and the 
implementor wishes to make these private extensions of the 
standard publicly available (so that others might support 
them), the Conformance Statement must contain a detailed 
definition of the SOP class* In short, the implementor is re- 
quired to replicate the relevant sections of NEMA publica- 
tions PS 3.3, PS3.4, and PS 3.6 in the Conformance State- 
ment. 

6. CONCLUSIONS 

A properly structured Conformance Statement must ac- 
company all DICOM products. It is incumbent on the manu- 
facturer to assure that published Conformance Statements 
are valid (i.e., that they match the associated implementa- 
tion). This is a vital requirement that must be met by ven- 
dors if the DICOM standard is to make a positive impact on 
the medical imaging market. The responsibility for enforce- 
ment lies with the user community. If a vendor says that its 
product supports DICOM, the user community must univer- 
sally respond: "Show me your Conformance Statement!" 
Without a Conformance Statement, a system does not com- 
ply with the standard. 
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SUMMARY 

The DICOM standard has been approved by ACR and 
NEMA in October 1993 and is being adopted as a European 
standard called MEDICOM. It represents a major break- 
through in the communication of medical images in an elec- 
tronic form. DICOM has been designed to take advantage 
of the increasing use of computer networks in health care. 
This article focuses on the network communication as well 
as introduces the extension of DICOM for media inter- 
change that is to be approved late in 1994. 

1. DICOM FOR OPEN NETWORKING 

Figure 1 presents a graphical overview of the three applica- 
tion networking capabilities supported by DICOM (NEMA 
PS3-1 through NEMA PS3-8): 

1. Network Image Transfer 

2. Print Management 

3. Imaging Study Management 

Various medical imaging applications may use these 
three networking capabilities, which in turn are supported 
by lower layers of general-purpose networking technology 
DICOM identifies a clear and generic boundary shown as a 
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Figure 1. The Three Dimensions 
of Networking with DICOM 

Figure 2. The elements used by 
DICOM for networking communi- 
cation support. 
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black plane in Figure 1, to provide maximum independence 
of the imaging networking capabilities from the technolo- 
gies used for building logical and physical networks (e.g., 
transport and routing protocols, physical network inter- 
faces, and cables). The manner in which the DICOM net- 
working services are supported by generally available net- 
work technologies will be discussed first, followed by the 
DICOM networking services themselves. 

Figure 2 depicts the functional components that DICOM 
has standardized below this generic boundary (called the 
generic OSI upper-layer services). These components are 
not specific to medical imaging but are general-purpose 
standards commonly available from the computer and tele- 
communication industry. They are specified in part 8 
(NEMA PS3-8) of the DICOM standard. 

Part 8 of DICOM allows two choices of functionally 
equivalent networking standards to ensure the reliable and 



efficient transfer of the DICOM messages. The first is 
based on the Transport Control Protocol/Internetwork Pro- 
tocol, or TCP/IP It results from a standardization effort by 
the U.S. Department of Defense in the early 1980s and is 
broadly used by the computer industry today. The vast ma- 
jority of DICOM implementations available on the market 
today have selected this approach. The second, Open Sys- 
tem Interconnection (OSI), is based on a set of ISO stan- 
dards. Even though OSI is the result of a massive stan- 
dardization effort performed in the late 1980s, it is in lim- 
ited use at the present time. 

At the physical networking level, DICOM supports a 
large variety of cost-effective local area (LAN) and wide 
area network (WAN) technologies. (Only a few are shown in 
Figure 2.). No restriction of choice is imposed by DICOM, 
because a logical seamless network can be built by combin- 
ing the use of several of these types of physical networks. 
This flexibility allows the design of cost-effective configura- 
tions to satisfy virtually the needs of any health care insti- 
tution. Most implementations of DICOM have selected 
Ethernet. 

Image Transfer 

The image transfer services of DICOM form the most 
broadly implemented part of the standard. These applica- 
tion-level services rely on the above networking protocols. 
They are specified mainly by DICOM part 4 (PS3-4). Two 
basic networking capabilities, called DICOM service 
classes, are defined: 

1. The storage service class 

2. The query/retrieve service class 

When implementing the storage service class, a sending 
DICOM application can send ("push") an image to a receiv- 
ing application. If repeated for every image of a study, an 
entire study may be pushed across the network. With this 
basic service class, the sender does not have the ability to 
request that a certain usage or processing be performed 



Figure 3. The structure of the 
DtCOW image transfer service 
dosses. 
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Figure 4. The DfCOM image infor- 
mation objects and the storage ser- 
vice class. 




with the image. It is the receiver's decision. The storage 
service class in DICOM part 4 specifies transfer operations 
common to all types of images (called information objects) 
irrespective of the modality. In part 3 of DICOM, a wide 
choice of image information objects is defined to support a 
wide range of imaging modalities. 

When implementing the query/retrieve service class, one 
DICOM application has the ability to search a remote 
node's database for patient records, studies, series of im- 
ages, and even individual images. Once selected, the corre- 
sponding image or images may be requested or retrieved. 



The storage service class is used to actually transfer the re- 
quested image(s). The combined used of the query/retrieve 
and storage service classes provides the ability to retrieve 
("pull") a set of images from a remote node. 

The DICOM storage service class defines a large choice 
of modality images. These are presented in Figure 4. These 
modality image objects are specified in DICOM part 3 
(PS3-3). Five modalities are addressed: Computed 
tomography (CT), magnetic resonance (MR) imaging, com- 
puted radiography (CR), ultrasound (US), and nuclear 
medicine (NM). In addition, digitizers, frame grabbers, 
and soft screen capture are addressed by the secondary 
capture (SC) and standalone overlay (e.g., text screen) in- 
formation objects. Finally, look-up tables of different type 
are supported by modality or VOI LUT objects. 

The support of radiographic images (angiographic or 
cardiovascular as well as fluoroscopic images) is expected 
to be approved late in 1994 as two supplements to the 
DICOM standard. 

Such information objects include not only the definition 
of the pixel data structure but also the related information 
that ensures appropriate use of the image pixel data. It 
provides a precise definition for each attribute of an image. 
The effective interoperability achieved by DICOM is 
largely based on this highly structured specification. 

DICOM Conformance 

The same figure that illustrates the DICOM networking 
capabilities may be used to introduce the role of a DICOM 
Conformance Statement (Fig 5). A DICOM Conformance 
Statement identifies which DICOM building blocks are 
implemented in a product. In the example below, the imple- 
mentation claims to support query/ retrieve and the stor- 
age of MR images with TCP/IP over Ethernet. 

DICOM requires that every implementation claiming 
conformance to DICOM provide a Conformance Statement. 
By comparing the Conformance Statements side by side, 
one will be able to assess the communication abilities of two 
implementations. 



Figure 5. A DICOM Conform- 
ance Statement states which 
building is implemented in a 
product. 

Figure 6. DICOM imaging study 
management. 




Network Imaging Study Management 

The second major capability provided by DICOM is the 
exchange of information that allows the management of im- 
aging studies. This building block (Fig 6) may coexist and 
be integrated with the exchange of images as described in 
the previous section. 

This capability is often called the "HIS/RIS-PACS inter- 
face" It is based on an information model that defines the 
relationship between the management of information and 
images. This feature is key for providing productivity im- 
provements within the hospital. It includes three service 
classes defined in DICOM part 4: 

1. The study management service class provides a means 
to obtain study information (before and after acquisi- 
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Figure 7. Example of use of the 
imaging study management ser- 
vice classes. 
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tion). It allows the tracking of the study status and its 
image content by avoiding reentry of information and 
associated potential errors. 

2. The patient management service class provides a 
means to obtain patient demographics that, like the 
study management service class, avoids reentry. It en- 
ables performance optimization such as the 
prefetching of images. 

3. The results management service class provides the 
means to obtain result information and corresponding 
interpretations both for prior studies as well as for the 
electronic management of results (review and ap- 
proval of reports). 

These service classes will be used by acquisition systems 
and workstations for the building of an integrated image 
management environment. A typical example of how the 
standard may be used is depicted in Figure 7. 

Network Print Management 

The third major networking capability provided by 
DICOM is the ability to print images on a networked 
hardcopy device (e.g., a laser camera). This building block 
(Fig 8) is called the print management service class. It is 
specified in DICOM part 4 (NEMA PS3-4). 
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Figure 8. The print manage- 
ment building block of DICOM. 



This service class is structured to support basic print 
management (either gray-scale or color). It provides: 

• The support of preformatted or camera-ready images, 

• The control of film layout (film format, magnification, 
number of copies, etc.), and 

• The management of the printing device (magazine low/ 
empty, out-of-service, etc.). 

This basic print management service may be extended 
by one or more of the following options: 

• Print Job management (e.g., being notified when the 
film is available from the processor); 

• Print by image reference (the printer is provided a full 
resolution image); and 

• Annotation and overlay (the printer may be instructed 
to place a textual banner on a film). 

A new part 13 of DICOM was approved in September 
1994 to support a non-network interface of printers. This 
point-to-point extension has been designed to use the type 
of physical interfaces commonly used by the hard-copy in- 
dustry today (a parallel interface for pixel input and an 
asynchronous link for DICOM print management control). 




2. DICOM MEDIA STORAGE 

Late in 1994, a set of supplements to DICOM "networking" 
is expected to be submitted for final approval These 
supplements provide a comprehensive approach to the stor- 
age of images and related information on media of various 
types (disks, tapes, etc.). These supplements extend 
DICOM by introducing three new parts to the standard. 

The DICOM approach to media storage is based on an 
architecture similar to the one successfully used in the net- 
working arena (Fig 9). It is based on a number of funda- 
mental principles: 

1. A number of industry standard media storage tech- 
nologies (magnetic disks, optical disks, tapes, etc.) are 
available, and none should be excluded a priori . Dif- 
ferent application contexts are likely to require that 
more than one technology be supported by DICOM. 

2. The evolution of physical storage media as well as cor- 
responding media formats (e.g., file systems) is not 
primarily driven by the medical imaging industry but 
rather by the computer and multimedia industry 
DICOM should not invent new choices but rather se- 
lect the most appropriate one^. 

3. The information objects used are identical to the ones 
used in the network. This is key for facilitating the in- 



tegration of network and media storage exchange. 

A number of supplements to DICOM are now "frozen" 
and will be submitted for final balloting in October 1994. As 
a consequence, three new parts will be added to the 
DICOM standard: 

1. Part 10, which specifies the general DICOM media 
storage architecture as well the file format to encap- 
sulate any DICOM-defined information object. With 
Part 10 comes the definition of a medical directory 
that facilitates direct access to selected images on the 
media. 

2. Part 12, which reference industry specifications for 
the Physical Media and Media formatting file systems. 
The first version is expected to include five types of 
media: CD-ROM, 574 magneto-optical disk (MOD) 
(650 Mbyte), MOD (1.3 Gbyte), 3V 4 MOD (128 
Mbyte), and the 3V2-inch DOS floppy disk. 

3. Part 11, which defines application-specific profiles. A 
profile is a simple means for users and vendors to 
specify a selection of physical media among those in 
part 12 and of information objects among those de- 
fined by DICOM part 3. 

CONCLUSION 

This brief overview of the content of the DICOM standard 
and of the supplements that are to be finalized late in 1994 
should demonstrate the breath of applicability of the stan- 
dard in creating open image management systems. 



CHAPTER 3 
Demonstrations 
of DICOM 



In January 1992, the MedPacs section of NEMA formed an 
ad hoc committee charged with developing specifications for 
an infoRAD demonstration of the evolving DICOM 3.0 stan- 
dard. Such demonstration was seen as a logical expansion of 
the 1990 demonstration of the ACR-NEMA point-to-point 
operation at the Georgetown University hospital (1). 

It was also decided that such an infoRAD demonstration 
should introduce the network communication specified in 
part 8 of the DICOM standard. Subsequent meetings re- 
sulted in the decision to specify performance for a 1993 
infoRAD demonstration and also to demonstrate a limited 
version in 1992. It was furthermore decided that an aca- 
demic institution should be funded to develop prototype 
software for a central test node (CTN). The DICOM stan- 
dard does not prescribe or require such a CTN but specifies 
an open network on which all participating nodes can com- 
municate directly. The CTN, however, was seen as a test 
suite for various implementations and an efficient method of 
assuring compatibility. Since an offer by the Electronic 
Communications Committee existed, it was decided to ask 
RSNA to manage the demonstrations within the infoRAD 
exhibit. On April 13, 1992, RSNA invited 12 institutions to 
generate DICOM software for a CTN (Table 1). 

The functionality of the 1992 demonstration was deliber- 
ately limited: 
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Only two of the commands ("services") were imple- 
mented (STORE and ECHO). These two sufficed, 
however, to demonstrate transmission of test images 
between CTN and demonstration prototype nodes 
(DPNs). 



Table 1 

Name of institution Submit Elected 

Bowman Gray 
Georgetown U. 

HUP X 
Johns Hopkins 

Mallinckrodt X X 

Mass General 
Shands U (Fl) 
UCLA 

UCSF X 
UNC 

UPitt 

UWA Seattle 



2. Test images of clinical significance were supplied by 
academic institutions. 

3. Ethernet was chosen but modified for faster response. 
The logical CTN performance was physically dupli- 
cated by eight CTNs so that only three DPNs had to 
share one (physical) CTN. 

4. The DPNs were exhibited as "works in progress" and 
not as salable products. 

They were not connected to image-generating equipment 
of the respective company. 

On July 15, 1992, the Electronic Radiology Laboratory 
(ERL) of Mallinckrodt Institute of Radiology, under G. J. 
Blaine, DSc, conducted a workshop on the CTN prototype 
software implementation. The software was made available 
in computer-readable form as well as paper documentation 
to all participants. 

On September 15, 1992, RSNA organized a test in Chi- 
cago that demonstrated on the first day that all participants 
could successfully communicate with the assigned CTNs. 

As Table 2 shows, 20 commercial companies participated 



Table 2 


Company 


1992 
Demo 


1993 
Demo 


DICOMnet RSNAnet 
1993 1993 


AAAI 




X 




Acuson 




X 




ADAC 


X 


X 


X 


AGFA 


X 


X 


X X 


ALI 


X 






ATL 




X 




Cemax 


X 


X 


X X 


Dupont 


X 


X 




Fischer 


X 






GE 


X 


X 


X X 


IBM 


X 






ICON 


X 


X 


X X 


ISG 


X 






Kodak 


X 


X 




Konica 




X 


X 


Loral 




X 


X 


Merge 


X 


X 


X 


Mitra 




X 


X X 


MMM 


X 






Olicon 


X 






ROCS 


X 






Philips 


X 


X 


X 


Picker 


X 


X 


X X 


Siemens 




X 


X 


Star 




X 




Toshiba 


X 






Virt. Imaging 


X 






Vortech 


X 


X 





in the 1992 demonstration. 

The DICOM demonstration at the RSNA 1993 meeting 
was an activity of the RSNA Electronic Communications 



Committee. With written specifications from NEMA, 
RSNA managed the project, designed and installed the ex- 
hibit and its electronic network, and funded the develop- 
ment of prototype CTN software through contract with the 
ERL of the Mallinckrodt Institute of Radiology. 

The 1993 infoRAD demonstration significantly extended 
the functionality 

• HIS and PACS services (e.g., patient admission notifi- 
cation, order entry notification, study completion noti- 
fication, study results reporting, and various queries 
on the patient, modality, study and series level) were 
added. 

• Image transfer from all "public" image stores, not 
only the assigned ones. 

These public stores also contained images generated by a 
particular vendor. 

• A second CTN design generated by a European con- 
sortium was incorporated. 

• Ethernet and FDDI links were offered for transmis- 
sion of images and other information between the 
infoRAD exhibit and the main exhibit floor. 

Table 2 lists 19 companies that participated in the 1993 
infoRAD demonstration; 10 also participated in the 1992 
demonstration and 10 companies used extension links to 
their respective booths on the main exhibit floor via the 
DICOMnet. In addition, eight companies transmitted im- 
ages on the RSNAnet. 

The two infoRAD demonstrations were successful be- 
cause of the enthusiastic cooperation between a profes- 
sional society (Radiological Society of North America), an 
academic institute (Mallinckrodt Institute of Radiology), 
and a trade association (NEMA). None of them could have 
succeeded alone with this ambitious project. It should also 
be mentioned that ACR has contributed greatly to the de- 



velopment of the DICOM standard and its demonstrations 
in 1992 and 1993. 

These demonstrations, however, omitted the one aspect 
that is expected of the DICOM standard: interoperativity 
of heterogeneous systems. The DPNs represented develop- 
ment of various companies and various forms of implemen- 
tation but were not diagnostic workstations as installed in 
many radiology departments. Digital diagnostic modalities 
such as CT, magnetic resonance imaging, computed radiog- 
raphy, ultrasound, and nuclear medicine systems produce 
valuable information in digital form that is incompatible 
and often undecipherable for general usage. Although the 
m/oRAD demonstrations did not address this problem of 
heterogeneity, they made a significant contribution to clari- 
fication. TWenty-eight companies that participated in these 
demonstrations were able to design and construct in a short 
time a DPN (or DN, as it was called for the 1993 demon- 
stration) that proved capable of communicating with the 
CTNs according to the DICOM 3.0 standard. Therefore, al- 
though not proven successful, direct communication accord- 
ing to the standard is fully plausible. Supplying information 
to the DPN and DNs from image-generating equipment is 
a company-specific task. If a company demonstrated that it 
could produce DICOM-conformant communication with a 
DN, it should be equally capable of moving data from pro- 
prietary imaging equipment into such a DN. 

The 1994 info RAD demonstration will encourage live 
communication between DICOM stations and diagnostic 
workstations of their product line. 

The real-world implementation will, therefore, combine 
heterogeneous imaging equipment, DNs, or gateways into a 
homogeneous environment and other systems that are com- 
patible, by design, with the homogeneous PAC system. 

Reference 

1. Horii SC. Hill DG, Blume HR, et aL An update on ACR-NEMA 
standard activity J Digit Imaging 1990; 3:146-151. 



The 

Mallinckrodt 
Institute of 
Radiology 
Prototype 
CTN 
Software 

Steven M. Moore 



The Mallinckrodt Institute of Radiology (MIR) software 
was developed in two stages. The software developed in 
1992 supported the completed part 8 of the DICOM stan- 
dard but used images and messages from ACR-NEMA Ver- 
sion 2. The 1993 software provided a DICOM implementa- 
tion that was based on the DICOM V3.0 draft standard 
(September, 1993) that was balloted and approved by 
NEMA (October 1993). The 1993 CTN software supported 
image transmission (store, query, and move), printing on re- 
mote printers and communication in an HIS/RIS/PACS en- 
vironment. 

The software is written in ANSI C and tested on UNIX- 
based workstations as offered by Sun Microsystems, Digital 
Equipment Corporation, and Silicon Graphics. Some MIR 
CTN software that uses calls to the operating system may 
not compile under other versions of UNIX (for example, as 
supplied by Hewlett Packard) but can be easily modified. 

The MIR software consists of the following pieces: 



1. Subroutine libraries 

2. Demonstration programs 

3. Test programs 

4. Documentation 



Some subroutine libraries were designed and written to 
support various parts of the DICOM standard. These li- 
braries served as the infrastructure for a number of the 
MIR demonstration and test applications. An example of 
such a library was the software written to implement the 
DICOM upper-layer protocol defined in part 8 of the stan- 
dard. Other subroutine libraries were written to support 
particular needs of demonstration programs that are not di- 
rect requirements of the standard. An example of such a 
subroutine is the code which supports error messages. 

Demonstration programs were written to fulfill specific 
requirements and to demonstrate particular aspects of the 
DICOM standard. The applications that were used in the 



1993 RSNA DICOM demonstrations in the infbBAD area 
are described below. 

• An image server program was developed that sup- 
ported DICOM communications for storage and re- 
trieval of images. Vendors could send images to the 
image server using the DICOM storage SOP classes 
and could retrieve the same or other images using the 
DICOM query-and-retrieve SOP classes. The image 
server also supported the verification SOP class. To be 
specific, the image server supported the storage, 
query-and-retrieve, and verification SOP classes as an 
SCP 

• An image client program was developed that sup- 
ported DICOM communications for sending images to 
vendor nodes. The image client program allowed users 
to login and list studies and images that had been 
stored by the image server. The image client program 
allowed the user to send images (complete studies) to 
a vendor node using one or more of the DICOM stor- 
age SOP classes. The image client program was an 
SCU of the verification and storage SOP classes. The 
image client program did not perform DICOM query- 
and-retrieve functions. A print manager program used 
a fixed set of images stored in simple database and al- 
lowed a user to establish a print session with a 
DICOM printer to print the images. The print man- 
ager had an Athena widget-based graphical user in- 
terface that presented print information to the user 
and allowed the user to set parameters for a DICOM 
print session. The user could also manipulate iconified 
versions of images to control placement on the print 
page (film). As the user manipulated the print param- 
eters and icons, the print manager sent DICOM print 
commands to a vendor's printer. A full, basic print ses- 
sion was completed. The print manager implemented 
the Basic Grayscale Print Management Meta SOP 
Class as an SCU. 



Two other applications were developed for the 1993 
RSNA DICOM demonstration but were not actually used 
during the RSNA annual meeting. Two applications were 
written that simulated the interaction between an HIS and a 
PACS. The simulated HIS presented a graphical user inter- 
face that allowed the user to enter information into a simple 
HIS and to send event reports by means of DICOM commu- 
nications to an external (vendor) node. The user could trig- 
ger numerous event notifications such as Study Scheduled, 
Study Completed, and Patient Created. The simulated HIS 
also included a server that had access to the same database. 
External (vendor) applications could establish DICOM asso- 
ciations with the HIS server and retrieve (DICOM N-Get) 
information from the server. 

The simulated PACS performed a set of functions de- 
signed to complement the simulated HIS. The simulated 
PACS had a server program that accepted event reports 
from an HIS. The simulated PACS also had a graphical user 
interface that displayed event reports to the user. In re- 
sponse to event notifications, the user could direct the PACS 
to query the HIS to retrieve additional information. This re- 
trieval was implemented with DICOM communication. 

A number of test programs were developed with the MIR 
software. These programs allow developers to create, exam- 
ine, and modify DICOM information objects, establish 
simple DICOM associations to test connectivity and DICOM 
functionality (store, query, and echo), and test the internal 
facilities (database and queues) that were developed to sup- 
port demonstrations. 

The MIR software contains documentation that describes 
the following: 

1. Overview of the RSNA DICOM demonstration and the 
functions provided by the MIR software. 

2. Examples of protocol data units that help the reader 
understand part 8 of the standard. 

3. Installation and test procedure. 

4. Guide to using demonstration and test applications. 

5. Programming guides to all subroutine libraries. 



As mentioned above, the MIR software contains a num- 
ber of subroutine libraries that are used to implement the 
various parts of the DICOM standard. Included below is a 
short description of the subroutines that provide this sup- 
port. Other subroutine libraries are included and docu- 
mented with the software but are not listed here. 

DCM - DICOM Information Objects 

The DCM facility provides functions for manipulating 
DICOM information objects. These routines encode and de- 
code objects per part 5 of the standard and allow the caller 
to perform simple operations (add, delete, modify) on indi- 
vidual elements. 

DUL - DICOM Upper Layer Protocol 
The DUL facility provides routines for implementing the 
DICOM upper-layer protocol with TCP/IP The routines are 
used to create and tear down associations and to exchange 
data over established associations. 

IE - Information Entity Verification 

The IE facility provides functions for examining DICOM 
Information objects to make certain they conform to the 
rules specified in part 3 of the standard. 

MSG - DICOM Messages 

The MSG facility defines a set of fixed structures that con- 
tain the parameters for the request and response messages 
defined for the DIMSE-C and DIMSE-N services. The fa- 
cility provides functions for translating these structures to 
and from the DCM representation of DCM information ob- 
jects so the messages can be sent to and received from a 
peer application over an association. 

SRV-DIMSE Services 

The SRV facility supports the DIMSE-C and DIMSE-N 
services by controlling messages which are sent to and re- 
ceived from the network. This facility provides a general 
framework that allows applications to actually implement 



the service classes defined in part 4 of the standard. 

UID - Generate and Maintain Unique Identifiers 

The UID facility provides a simple mechanism for generat- 
ing unique identifiers in accordance with requirements of 
the DICOM standard. 

As a side note, the functionality of demonstration pro- 
grams depends on the evolution of the standard and re- 
quirements for demonstrations at the RSNA. Some MIR 
demonstration programs support odd features that are di- 
rect requirements of operating in a demonstration environ- 
ment. As new requirements arise, demonstration programs 
may be replaced with a new version of the program or may 
be retired as the developers, RSNA, and NEMA find differ- 
ent ways to demonstrate the DICOM standard. 
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As part of the RSNA '93 infoRAD demonstration of DICOM 
3.0, a European central test node (CTN) was developed. Un- 
der the auspices of CEN (the European Standardization 
Committee), several institutions have cooperated to produce 
a European CTN implementation. Oldenburg University 
and the OFFIS Institute in Oldenburg, Germany, coordi- 
nated the development effort as well as implemented the 
CTN network software, DICOM information object encod- 
ing and decoding, CTN display and performed system inte- 
gration activities. CERIUM in Rennes, France, developed 
the DICOM storage and query/retrieve service classes and 
associated database functionality. PRIMIS in Brussels, Bel- 
gium, has concentrated on producing sample sets of DICOM 
images. 

For the purposes of work package separation and under- 
standability, the breakup of software modules closely fol- 
lows the various parts of the DICOM standard. In particu- 
lar, a simple interface was defined between the software 
components developed in Oldenburg and those developed in 
Rennes. In order to efficiently cope with additions and 
changed in the DICOM data dictionary before it was final- 



ized, a code generation facility was used to generate tag, 
value representation, and type definitions from tables ex- 
tracted from electronic versions of the DICOM documents. 
Also considered were general mechanisms for handling se- 
quences of items that will be particularly useful for imple- 
mentation of DICOM media storage. The European CTN 
display was designed to be able to handle many vendors be- 
ing assigned to a single CTN. Only the most recent activi- 
ties are visible in the display, and image areas are not as- 
signed to fixed vendors. The OFFIS Institute in Oldenburg 
has also developed software for exporting DICOM images 
into other formats. One external format considered was 
TIFF, which is useful for exporting to desktop publishing 
applications. Another format is image processing inter- 
change (IPI), which is an ISO standard and is likely to be of 
particular importance in image processing applications. 

All involved institutions are continuing development of 
DICOM software. In Oldenburg, work has already started 
on an object-oriented library for manipulating DICOM in- 
formation objects. DICOM print client and server software 
is also under development 

The European DICOM software (source code and docu- 
mentation) is publicly available and can be obtained via 
Internet FTP (ftp.uni-oldenburg.de in the directory /pub/ 
dicom/dicom_software/European). 
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Figure 1 shows a "message generator" patterned after the 
parts of the DICOM standard. A key information structure 
is the "message" and its fragments, the PDUs. The stan- 
dard does not make a clear distinction between the overall 
message and its fragments into PDUs, it equates a PDU 
with a message. The term "global message" could be used 
to refer to a block of data comprising a complete transfer. 
For technical reasons the global message is fragmented into 
PDUs. Such a PDU consists of an SOP and an association 
control header as indicated in Figure 1. 

HOMOGENEOUS ENTITIES VERSUS 
HETEROGENEOUS ENVIRONMENTS 

Implementation of the DICOM standard establishes an 
open system in the sense that communication between het- 
erogeneous environments can be accomplished by means of 
homogeneous (standardized) information entities. 

PDUs are standardized and transportable entities. They 
are generated by application entities (AEs) capable of per- 
forming certain tasks. It is important to remember that 
AEs are programs residing in "real-world" equipment, for 
instance a workstations (1). On the same workstation reside 
other programs possibly suitable for converting propri- 
etary data from an image acquisition system into data 
conformant with the DICOM standard. The AEs are nodes 
on the chosen network as specified in the Conformance 
Statement. 



ESSENTIAL FACILITIES 

The essential facilities are called DIMSE and ACSE in the 
DICOM language: DICOM message service elements 
(DIMSEs) and association control service elements 



Message Generator 



AE Definitions 
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See Glossary for abbreviations 



(ACSEs). One can think of such DIMSEs as a message gen- 
erator that uses various supplies of information. As indi- 
cated in Figure 1, IOD modules supply information data and 
command elements. A dictionary of UIDs supplies appropri- 
ate UIDs for the AE. 

The calling AE must use the data format of the IOD 
modules and enter the appropriate data values coded ac- 
cording to the VR specifications. A list of specified modules 
is included in Table 1, and Table 2 gives a specific example 
for a set of CT modules. 

A specific AE implemented on a particular computer 
platform and a specific network node will use a particular 
implementation program while another AE on another plat- 
form and node uses different software, but the same IOD 
module will be used to generate the same information ele- 



merits. But both nodes (i.e., workstations on the network) 
can reverse roles and understand the PDUs generated by 
the other node. The essential prerequisite is conformance of 
the PDUs and their interpretations. 

SOURCES OF DATA ELEMENT VALUES 

The attributes of the required information objects are ex- 
pressed by data elements. The values of the data elements 
are derived from several sources, e.g. : 

• equipment and data links to image generating sys- 
tems, preferable via automated transfer; 

• a network connection to an RIS or HIS; and 

• keyboards or bar code readers, which may require 
checking and verification. 

The standard lists 545 data elements in 12 groups with 
new ones being suggested for various new information ob- 
jects. Table 2 lists only data elements of types 1 and 2, but 
this may not be sufficient for a PACS installation. Some op- 
tional data elements will be needed and a response to all of 
them is required. 

THE ASSOCIATION CONTROL SERVICE 
ELEMENTS 

The ASCEs define a capability for establishing and termi- 
nating an association according to part 8 of the standard. All 
PDUs include a header dealing with such association primi- 
tives. The last 4 bytes of the ASCE header constitute the 
message control header, which indicates whether the follow- 
ing PDU contains data or a command and whether it is the 
last of such PDUs. 

Figure 1 illustrates only PDU generation by a calling 
AE. A corresponding "engine" is required at the called AE. 
Incoming packets are reassembled by the TCP/IP engine 
into PDUs, which, in turn, must be checked for errors or 



omissions such as missing mandatory information elements. 
In such a case, the existing association will be discontinued 
and a new association in the reverse direction will be estab- 
lished in order to report the omission. 

If the called AE does not have sufficient storage space 
for a complete image, the calling AE must be informed. 

Global Design Requirements 

A real-world implementation will deal with various AEs 
performing a variety of tasks. The DICOM standard does 
not deal with such an aspect. Part 1 states: 

"The DICOM Standard does not specify: 

"The overall set of features and functions to be ex- 
pected from a system implemented by integrating a 
group of devices each claiming DICOM conformance." 

Checking the Conformance Statements of two systems 
may not be sufficient. All participating nodes must be com- 
patible with respect to the intended tasks (SOPs and AEs). 
This may mean that a valid response to all of the optional 
data elements must be incorporated. The infoRAD demon- 
strations addressed only a limited number of nodes and 
AEs and a limited number of data elements. 

In a real-world implementation, the nodes (physical 
workstations) will play various roles and activate corre- 
sponding AEs. A global mapping is needed so that all re- 
quired tasks can be performed without discrepancies or du- 
plications. Such a global design will also generate a list of 
UIDs (2). 

Part 3 of the standard lists the modules in Table 2. 
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Forty mandatory data elements are required in 11 mod- 
ules. Some of these data elements can be supplied through 
interfaces from a RIS or HIS. For instance, for scheduled 
studies the patient's name, identification number, date of 
birth, and sex can be transferred. The CT scanner could 
provide image number (0028,0030), image date and time, 
and manufacturer's identification number (0008,0070). The 
"Series No" (0020,0010) could be linked to the "frame-of- 
reference UID" ( 0020,0052) and the position reference indi- 
cator (0020,1040). 

Most of the pixel information can be determined by the 
choice of CT examination, e.g. pixel spacing (0028,0030), 
slice thickness (0018,0050), etc. All of the data elements of 
the image pixel module are machine related and constant 
for a particular CT system. Overlay data elements are also 
fixed for a particular CT display system. Overlay informa- 
tion, though, is usually put on CT images in visual, not bi- 
nary, coding. 

The operator may have to enter the SOP class instance 
UID (0008,0018) and the frame-of-reference UID 
(0020,0052). 

A user-friendly design would provide templates for stud- 
ies with preset data elements and interfaces to other sys- 
tems that supply required data elements. Type 2 data ele- 
ments must be listed but can be entered later. An individual 
implementation may include optional data elements (type 
3). Participating AEs of a global design must be capable of 
recognizing these and take appropriate action. Therefore, a 
CT template may contain more than 40 data elements. 

All this requires nontrivial design of hardware and soft- 
ware. It is unrealistic, though, to expect error-free entry of 
all these data elements by an operator. Operator entries 
should be reduced to the absolute minimum and should be 
supervised by an entry checking and correcting algorithm. 

DICOM 3.0 implementations are expected to provide ro- 
bust and efficient access to imaging information. Entry of 
the required data elements must not slow down the tech- 
nologist. The standard does not deal with the complexity of 
this task, but the implementer must. Implementation and 



interfacing products, described later in this chapter, will 
supply information related to this task. 
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In this example, an SCU of the CT storage SOP class has a 
stripped CT image. The stripped image is used to reduce 
the size of the example. Several data PDUs are presented 
that show the C-store command and the data set (CT im- 
age) that complete the C-store message. 



Byte 


Value 


Interpretation 


1 


04 


PDU Type : P-DATA 


2 


00 


Reserved 


3 


00 00 00 81 


PDU length: 129 


7 


00 00 00 7D 


PDV length: 125 


11 


01 


Presentation Context ID 


12 


03 


Message Control Header 


13 


00 00 00 00 


TAG group length 


17 


04 00 00 00 


Element length 


21 


76 00 00 00 


Group length 


25 


00 00 02 00 


Affected SOP Class UID 


29 


1A00 00 00 


Data length 


33 


31 2E 32 2E 38 34 30 2E 


1.2.840.10008.5.1.4.1.1.2 




31 30 30 30 38 2E 35 2E 






31 2E 34 2E 31 2E 31 2E 






32 00 




59 


00 00 00 01 


Command Field 


63 


02 00 00 00 


Length 


67 


01 00 


1 = STORE 


69 


00 00 10 10 


Message ID 


73 


02 00 00 00 


Length 


77 


01 00 


Message ID 


79 


00 00 00 07 


TAG, Priority 


83 


02 00 00 00 


Length 


8 


00 00 


Priority 0 


89 


00 00 00 08 


TAG Data type 


93 


02 00 00 00 


Length 
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97 00 00 

99 00 00 00 10 

103 24 00 00 00 
107 31 2E 32 2E 38 34 30 2E 
31 30 30 30 38 2E 35 2E 

31 2E 34 2E 31 2E 31 2E 

32 2E 36 00 



TyreO 

TAG SOP affected 

instance 
Length 36 

1.2.840.10008.5.1.4.1.1.2.5 



The second PDU contains one DATA PDV The data set in the 
PDV contains the beginning of the CT image. The rest of the 
PDU has been discarded for the sake of brevity. 



byte 


Value 


Interpretation 


i 

i 


fid 


± uu type. r-L/nin. 


o 


nn 


rveservea 


Q 
O 


nn nn ac\ nn 

uu UU 4U uu 


ruu lengxn viooo4j 


7 


nn nn t?p 

uu UU or P \j 


r\uv lengxn ^idoou^ 


11 


fit 
Ul 


Presentation context ID 


1 o 


AA 

00 


Message Control Header 


lo 


no t\f\ ta fin 
Uo Uu lu UU 


TAP QAD Plnon TT\ 

lAu oUr Ulass ID 


17 


1 A AA AA AA 

1 A 00 00 00 


Data length 


21 


31 2E 32 2E 38 34 30 2E 


1 .2.840. 1 0008.5. 1 .4. 1 . 1 .2 




Ol OA OA OA OD ATTl Ot AT71 

31 30 30 30 38 2E 35 2E 






Ol fiTTl O A OT71 01 OT71 O t OTTt 

31 2E 34 2E 31 2E 31 2E 






QO AA 

oZ UU 




47 


08 00 18 00 


TAG SOP Instance UID 


51 


24 00 00 00 


Data length (36) 


55 


31 2E 32 2E 38 34 30 2E 


1.2.840.10008.5.1.4.1.1.2.5 




31 30 3030 38 2E 35 2E 






31 2E 34 2E 31 2E 31 2E 






32 2E 35 00 00 00 00 00 






00 00 00 00 




91 


08 00 20 00 


TAG :study date 


95 


08 00 00 00 


Data length 


99 


31 39 39 33 30 35 31 38 


19930518 


107 


08 00 60 00 


TAG Modality 


111 


02 00 00 00 


Data length 


115 


43 54 


CT 


117 


10 00 10 00 


TAG Patient's Name 


121 


14 00 00 00 


Length 


125 


4A 45 46 46 45 52 53 4 


JEFFERSON ~ THOMAS 




4E 5E 54 48 4F 4D 41 53 






5E 5E 5E 20 




145 


10 00 20 00 


TAG Patient's ID 


149 


OA 00 00 00 


Length 



153 


4D 34 39 39 37 30 39 36 


M49970966 




36 20 




163 


10 00 30 00 


TAG Patient's Birthdate 


167 


08 00 00 00 


Length 


171 


31 39 34 33 30 37 30 34 


19430704 


179 


29 00 02 00 


TAG samples per pixel 


183 


02 00 00 00 


Length 


187 


01 00 


1 


189 


28 00 04 00 


TAG Photometr. Interpretation 


193 


0C 00 00 00 


Length 


197 


4D 4F 4E 4F 43 48 52 4F 


MONOCHROME2 




4D 45 32 20 




209 


28 00 10 00 


TAG # Rows 


213 


02 00 00 00 


Length 


217 


00 02 


(512) 


219 


28 00 11 00 


TAG # Columns 


223 


02 00 00 00 


Length 


227 


00 02 


(512) 


229 


28 00 00 01 


TAG: bits allocated 


233 


02 00 00 00 


Length 


237 


10 00 


(16) 


239 


28 00 01 01 


TAG: bits stored 


243 


02 00 00 00 


Length 


247 


ODOO 


(13) 


249 


28 00 02 01 


TAG: high bit 


253 


02 00 00 00 


Length 


257 


OC 00 


(12) 


259 


28 00 03 01 


TAG: pixel representation 


263 


02 00 00 00 


Length 


267 


01 00 


(1) 


269 


EO 7F 10 00 


TAG: Pixel data 


273 


00 00 08 00 


(524288) 


277 


00 80 00 80 


(pixel data....) 



There are a number of P-DATA PDUs that contain pixel 
data. The final PDU also contains pixel data but is of inter- 
est because it is the last PDU in the C-STORE message. 



Byte 


Value 


1 


04 


2 


00 


3 


00 00 01 0E 


7 


00 00 01 OA 


11 


01 


12 


02 


13 





Interpretation 
PDU type : P-DATA 
Reserved 
PDU length: 270 
PDV length: 266 
Presentation context ID 
Message Control Header 
Remaining pixel data 
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The Electronic Radiology Laboratory of Mallinckrodt Insti- 
tute of Radiology (MIR) has produced a comprehensive CT 
prototype software that is offered for public use. It is avail- 
able via Internet and also in document form and on com- 
puter medium from RSNA. 

The following announcement was made on February 8, 
1994: 

SOFTWARE RELEASE NOTICE 

The Radiological Society of North America and The 
Mallinckrodt Institute of Radiology are making available in 
the Public Domain, the software developed for the RSNA 
1993 DICOM demonstration. This release includes source 
code and all of the accompanying supporting documentation. 

This software was developed to enable demonstration of 
an implementation model according to the specifications 
from the DICOM 3.0 standard. It allows digital medical im- 
age communication over "open system" networks between 
multivendor and multimodahty imaging devices. 

You may obtain the software and documentation, free of 
charge, from the following Internet sites supporting the file 
transfer protocol (FTP). 



rsna.org [192.203.125.2] 
wuerlim.wustl.edu [128.252.118.15] 



If you do not have access to the Internet and you would 
like to obtain a tape containing the software and a hardcopy 
binder of the documentation you may choose to order it (for 
a fee) from: 



Radiological Society of North America 
Department of Informatics 

2021 Spring Road, Suite 600 • Oak Brook, IL 61021 
708-571-7810 



Formats: 

1. Anonymous FTP - Software Source Code and 
Postscript Documentation (free) 



2. Anonymous FTP - Software Source Code 

Mail Order - Hardcopy Binder Documentation 
(fee of $175) 

3. Mail Order - Software Source Code on 
8-mm Tape or l M" Cartridge Tape 
Hardcopy Binder Documentation 

(fee of $250) 

Four sites are offering Internet downloading of the DICOM 

documentation and the CTN software : 

MIR wuerlim.wustl.edu 128.252.118.15 

RSNA rsna.org 192.203.125.2 

PSU ftp.xray.hmc.psu.edu 



Oldenburg 

A review of the three U.S. logs resulted in the following es- 
timates : 



U. of 



http://www.xray.hmc.psu.edu 
ftp.uni-oldenburg.de 



MIR: 



149 

85 

32 

26 

27 



TOTAL accesses 



identifiable 
US *.edu 
US *.com 



International 



RSNA: 



600 
229 
91 



total accesses 
separate addresses 
by numbers 



PSU: In the first 4 months of 1994 
>2000 total accesses 



Software related accesses only : 



16 US *.edu 

30 US *.com 

35 International 

10 European software 



B. Commercial 

Implementation 

Strategies 
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Agfa's IMACS product line is based upon the products MG 
3000, LR3300, DI2000, AS3000, RS3000/5000, TS5000, and 
PS5000. FVom the start, Agfa took the strategic decision to 
benefit from the DICOM 3.0 standard. 

For each of the products mentioned above, Agfa defined 
the required implementation of DICOM service class, re- 
sulting in the inherent DICOM Conformance Statement. 

The newest equipment — the thermosublimation printer 
DI2000 — is conforming to DICOM 3.0 print management 
service class. 

Existing equipment such as the PS5000 of Agfa's phos- 
phor plate system will be upgraded to DICOM conformance 
through a software upgrade. 

Agfa's network is based on Ethernet IEEE 802.3, 
whereon TCP/IP with DICOM 3.0 is implemented. 

The requirements for interfacing to Agfa equipment are 
thus restricted to matching the DICOM Conformance 
Statements of third-party equipment with Agfa's. There- 
fore, Agfa provides the DICOM Conformance Statements 
of the products to the third party. Hence, the third party 
has all relevant information for the developing the interface 
to Agfa equipment. 

The following Table summarizes the relevant DICOM 
service classes to which the Agfa products conform with re- 
spect to third-party interfacing. 

Detailed product information is available from : 

Bob Cooke, Product Manager 
Agfa Division of Miles Inc. 
100 Challenger Rd. 
Ridgefield Park, NJ 07660 
Telephone: 201-440-2500 



Applicable Service Classes 

Pat/St 

Product Verif Storage Stdy/Not Query/R PrtMg ResMg. 

MG3C00 U/P U/P 
LR3000 

D12000 U/P U/P 

AS3000 U/P U/P 

RS3000 U/P U/P 

TS5000 U U 
PS5000 U U 

Note.— P = provider, PAtfSt = patient study, Prt Mg = print manager, 
Query/R = query/retrieve, Res. Mg. = results management, Stdy/Not. = 
study/notification, U = user, Verif. = verification. 

Source. — Reprint courtesy of Agfa-Gevaert N. V 



U 

u 

U/P 
U/P 

u 
u 



U/P 

u 



p 

u 

u 

u 
u 



u 
u 
u 



no 



CEMAX, Inc. offers a variety of DICOM services in its 
product line. 

ClinicalView acquires images from a wide variety of 
sources, distributes them to designated image review sta- 
tions, and displays them on high-resolution displays in the 
clinical ward. 

VIP is a full-function radiology image processing work- 
station, offering image display and analysis, two-dimen- 
sional (2D) and three-dimensional (3D) image reconstruc- 
tion, and advanced protocols for productivity in radiology. 

ACR-NEMA 1.0 and 2.0 formatted data is accepted from 
CX MR, and digital subtraction angiographic image 
sources and stored in CEMAX's database format for dis- 
play, archive, reformatting and other image processing, or 
export. Data from any source can be exported in ACR- 
NEMA 2.0 format, including original data and 2D and 3D 
reconstructed images. Complete 3D image geometry is in- 
cluded with each image. 

In both ClinicalView and VI? DICOM 3.0 storage ser- 
vice class provider is an integral part of CEMAX's 
ImageServer 1.0 product. It supports acquisition and stor- 
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age of computed radiography, CTJ MR imaging, ultrasound, 
and digitized film modalities. Original images obtained from 
scanners as well as derived 2 D and 3D reconstructed im- 
ages are accepted. 

CEMAX ImageServer exports original and recon- 
structed images as a DICOM storage class user. Image sets 
for export can be accepted at the individual image, series, 
or patient levels. Exported 3D images are exported as 8- 
bit gray-scale, RGB, or RGBA image objects. DICOM 3.0 
image geometry data is included with each image to enable 
cross-referencing between images. 

CEMAX's Network Film Server employs the DICOM 
print management service class to film to all major laser 
cameras. Via its Laser Link interface, Network Film 
Server acts as print service class provider for DICOM ba- 
sic grayscale print management service-object class. 

Network Film Server also incorporates a print manage- 
ment service class user for printing to cameras that accept 
the DICOM print protocol. 

CEMAX provides the DICOM 3.0 query/retrieve service 
class user capability for database access via patient identifi- 
cation number (ID), patient name, study, or series ID. Re- 
trieval is allowed at the patient, study, series, or image 
level. 

Additional information on CEMAX products and 
DICOM-conformant services can be obtained from Mat- 
thew Long, telephone 510-770-8612; fax 510-770-8555. 



No one can say with any great degree of certainty exactly 
what the global healthcare delivery system will look like in 5 
years, or 20. But before your hospital invests in an image 
information management system designed to take it well 
into the 21st century, with an eventual cost likely to range 
upwards — perhaps well upwards — of $3-$5 million, you 
would do well to give careful thought to the impact that de- 
cision will have on your entire hospital. False starts can 
carry an outrageous price tag in this critical area, effec- 
tively locking you into technology that may prove totally in- 
adequate to meet tomorrow's needs. 

WHAT DO WE KNOW FOR SURE 
ABOUT FUTURE NEEDS? 

Limiting your sights to the departmental level is 
yesterday's mindset. And the old PACS model, which fo- 
cused primarily on eliminating film, falls far short of need. 
Simply duplicating "the way we've always done things" elec- 
tronically ignores the clinician's needs and does little to im- 
prove the process — and your productivity. Yet unfortu- 
nately, most of the "solutions" on the table today are based 
on that outdated model ... rather than taking a longer view 
that can ultimately change and streamline the whole pro- 
cess by which health care is delivered. 

Choices you make today can have a major impact on the 
flexibility of your system to accommodate these kinds of 
changes. It's analogous to buying last year's computer sys- 
tem to do what's available today versus one that has enough 
built-in capabilities to handle advances in technology for a 
long time to come. 

THE MOST CRITICAL DECISION: DICOM OR 
PROPRIETARY? 

Many decisions can best be made at the appropriate point in 
the development of the system. There is, however, one 
early decision which must be on target from the outset; the 
penalty for misguessing is too steep, in terms of quickly ob- 
soleted equipment. 

Primary among these, in our opinion, is the design of the 
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system based on proprietary versus industry-wide medical 
networking standards. The value of the proprietary choice 
to users is short-term only. But it's easy to see why it has a 
strong attraction for vendors. After all, if it's only with this 
vendor's brand of equipment that your network functions 
smoothly, are you likely to want to buy from another vendor 
in the future? 

GE has chosen to take the longer view. Consider with 
whom you may need to exchange data asuse of remote diag- 
nosis expands. What is the likelihood that each data trans- 
fer will be with an institution whose selection of systems 
mirrors yours? Can you really afford to be limited in that 
way? or to invest in costly, complex "gateways" that may or 
may not work consistently or interface with other net- 
works? 

To us, the only solution that makes long-term sense for 
the health care industry is a worldwide system of linkable 
networks, providing maximum flexibility through an "open" 
architecture based on industry-wide standards — in other 
words, a complete DICOM system. 

DECISION TWO: WHAT VISION DO YOU LOOK FOR 
PROM A VENDOR? 

Network systems vendors typically fit into one of six catego- 
ries, listed here in order of increasing sophistication. Which 
approach you choose should depend on your own vision of 
the role of information management in your hospital for de- 
cades to come. 

• Digital Film Approach: These vendors, usually film 
companies, recognize the probable movement toward a 
filmless radiology department and are reacting accordingly. 
They offer a simple electronic alternative to film, with no 
focus on broader connectivity or to change in the radiology 
productivity model. 

• Niche Market Approach: Workstation suppliers are 
the most common entrants in this category. They focus on 
implementing the "optimum" workstation for one specific 
purpose — for instance, 3D images. There is limited inte- 



gration of this station with the entire radiology diagnostic 
process with the rest of the hospital's data. 

• Generic Network Approach: There are a number of 
vendors who understand physical networks very well but 
have little understanding about the unique information re- 
quirements, image analysis methods, and data flow needs 
associated with clinical applications. 

• Spigot Approach: These vendors provide scanners or 
workstations that use the DICOM standard to send or re- 
ceive radiologic images. It's up to you to locate vendors 
who supply complementary products such as local or wide- 
area network components and then to configure and inte- 
grate that network. If there are problems you will need to 
persuade each vendor to take responsibility for the mal- 
function. 

• Proprietary Solutions: As described in the previous 
section, these vendors may indeed provide a solution that's 
integrated, department-wide. It may include anything 
from proprietary data formats to proprietary network pro- 
tocols or storage devices. And it may work very well — as 
long as all devices on the network have the right brand 
name. These vendors may even claim DICOM compatibil- 
ity, since they can sell you "gateways" (usually used only to 
get data into the proprietary network.) The problem is 
that these greatly reduce the functionality of the DICOM 
devices. They can also be expensive, and clearly inject an 
additional level of complexity, which may cause additional 
problems. 

• Integrated Solution: A truly integrated system veri- 
fies that all devices on the network support the autofor- 
warding of all data needed to fill in workstation menu infor- 
mation, etc. This means that any vendor who understands 
radiology information and who supports an open architec- 
ture based on DICOM can provide the correct network and 
system components; you're not locked into any single 
source. And you can communicate freely with any other 
DICOM-based system, regardless of the manufacturer, 
without the need for gateways. Vendors capable of provid- 
ing components, design and system integration will be able 



to supply single-source accountability for network installa- 
tion, scanner connectivity, workstations, HIS/RIS connec- 
tivity, and complete field service. This is the route that GE 
has chosen. 

DECISION THREE: THE "BIG BANG" VERSUS 
THE PHASED APPROACH 

Some of the dozens of vendors in this emerging market- 
place have a broader vision of the ultimate goal than that 
provided by the old PACS model. But vision is only the first 
step. The difference is in the details; an implementation of 
the concept demands hundreds of design decisions, large 
and small. The impact of many of these will not be entirely 
clear until we as an industry have a good deal more experi- 
ence in a variety of clinical sites. 

There are essentially two approaches to this challenge: 

• The "Big Bang," or rush-to-judgment, technique says 
in effect, "Let's produce a total system to see how it all 
works together ... then go in later as necessary, to find fixes 
for the parts of it that cause problems for our users." 

• The Phased Approach — GE's choice — lets you take 
the process one step at a time. By fine-tuning strategies as 
clinical practitioners discover how this automated process 
affects the work environment, we can better tailor your sys- 
tem to real-world conditions. This enables you to build upon 
previous phases without replacing earlier investments and 
gives real significance to your input in the configuration of 
your network. 

We've identified four key phases as stepping stones to 
full realization of the vision: 

Phase One: Establish the Infrastructure. This phase 
lays down the hardware necessary to build the "information 
highway," moving information from where it is acquired to 
wherever it is needed — based on the DICOM standard, to 
allow maximum flexibility in connecting most manufactur- 
ers' products in the future. Phase one systems support 
transmission of image data to any DICOM-supporting de- 
vices on the network. (See next section for current list.) 



Phase Two: Automate the movement of image data 

from acquisition to display or storage. A network manager 
or server manages data flow, determines where it should be 
sent, and includes the ability to store images locally, wher- 
ever they are used. So that the system can be cost-effec- 
tively upgraded when and where needed, we've grouped 
systems in clusters; typically, each radiology department on 
the network would constitute one cluster. Each cluster can 
then advance to the next development phase independently, 
without affecting the overall performance of the system. 

Phase Three: Link the radiology network into the 
hospital's information systems to retrieve patient demo- 
graphics data and transfer scan information to other sys- 
tems outside of radiology. Key to this phase is tying differ- 
ent archive systems together with a large, centralized 
archive system that is electronically accessible throughout 
the hospital. 

Phase Four and Beyond: Combine diagnostic and 
other information from radiology and all the other depart- 
ments, laboratories, and patient wards. This will be a larger 
challenge than it appears at first glance, since neither stan- 
dards nor infrastructure exist yet. But with a phased ap- 
proach, the task will be manageable. 

HOW GE'S ID/NET INTEGRATES DICOM FOR 
MAXIMUM FLEXIBILITY 

GE recognized the need for industry-wide standards well 
before such standards even existed; and weVe been instru- 
mental in their development. Over the past 4 years, many 
GE representatives have been assigned to the DICOM com- 
mittees, edited several parts of the standard, and chaired a 
working group. We continue to be one of the most active 
contributors to its growth. 

That means we thoroughly understand the DICOM stan- 
dard. That understanding has already enabled us to inte- 
grate DICOM into a number of our own products, from the 
inside out , thereby demonstrating the effectiveness of its 
connectivity. Since January 1994, only a month after the 



DICOM demonstration at the annual RSNA scientific as- 
sembly in 1993, weVe introduced three DICOM-integrated 
image acquisition systems and two display, analysis, and 
storage workstations: 

• CT HiSpeed Advantage 

• CTHiLight Advantage 

• MR Advantage Signa 

• Advantage Windows Workstation 

• Advantage Independent Console 

And that's just the beginning. Coming up soon: 

• X-ray • MRVectra 

• R&F • Radiation Oncology Target 2 

• Vascular • PET Advance 

• CT9800 • Ultrasound Logic 700 

• CT ProSpeed • And a complete line of 

• CTSytec DICOM-based teleradiology 

products 

To maximize flexibility and lay the groundwork for an 
open architecture system, all these products will have 
DICOM integrated into each system. This assures that 
there will be no need for special translaters or "gateways" 
for communication with any other truly DICOM-based de- 
vice or network. 

We'll provide a wide range of DICOM-compatible sys- 
tems, including acquisition, analysis, distribution, display, 
storage, and image management. We'll also provide system 
integration: consultation, design, installation, service, and 
support for both local and wide area networks (WANs). GE 
Global Networks group is experienced in the design of 
simple or complex WANs. And GE Service, using InSite 
OnLine, has more than 5 years of remote service expertise 
for network problem analysis. With single-source account- 
ability for all communication needs, you can forget about 
dealing with such issues as LATA boundaries or Tl lines ... 
or about finger-pointing among various vendors. 



And of course, with 99 years as a leader in the diagnostic 
imaging business, we thoroughly understand your medical 
imaging and information requirements. You can rely upon 
our commitment to helping you meet your growing connec- 
tivity needs, far into the future — with systems that exem- 
plify the GE Continuum in action. ID/Net has been de- 
signed from the outset to keep going and going — keeping 
pace at every step with advancing technology. 



THE PAST 

Connectivity, through electronic communication and 
through media, plays an important role in the product policy 
of Philips Medical Systems (Philips). One of the first entries 
in the PACS market, the CommView system, was jointly de- 
veloped by Philips and AT&T Commview is currently in- 
stalled in many hospitals in the United States and Europe, 
and its development and use has provided a wealth of expe- 
rience that is used in the new DICOM-based Philips Con- 
nectivity Program. 

Prior to the ACR-NEMA standardization activities, 
Philips and Siemens cooperated in the development of the 
SPI interface definition. Especially for storage of images 
on disks, this has been used for a long time and is still sup- 
ported on several Philips modalities and EasyVision work- 
stations. 

Philips' prevailing protocol for communication of images 
is PMSnet, which uses the second version of the ACR- 
NEMA standard. It is either directly available from the 
modalities through EasyVision workstations or through 
special interfaces offered in cooperation with Merge Tech- 
nologies Inc. It is also used internally between Philips mo- 
dalities and EasyVision workstations. In this case, extra ap- 
plication functionality can be provided through private at- 
tributes that are not yet standardized. 
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DICOM 

Philips Medical Systems has actively supported the develop- 
ment of DICOM, which is the cornerstone of the new 



Philips Connectivity Program. DICOM not only enables im- 
age communication between vendors but also increases the 
opportunity for PACS functionality. Therefore, the Philips 
DICOM program is closely linked with the Philips Connec- 
tivity Program to offer PACS functionality at various levels 
of sophistication from department levels to complete hospi- 
tals and beyond. 

PHILIPS CONNECTIVITY PROGRAM 

The Philips Connectivity Program is based on the following 
key points: 

• Modalities will provide direct DICOM store services 
for the relevant imaging objects; for some older sys- 
tems this can be realized through special gateways. 

• The EasyVision product line consists of three product 
families: 

— modality-oriented productivity enhancers 
— stations for special clincial applications and 
— general application-and-review stations 

• DICOM store and query/retrieve service classes will 
be implemented for the objects that are relevant for 
the specific EasyVision workstation. 

• Stations for distributed viewing (teleradiolgy and criti- 
cal care) will use the DICOM store and query/retrieve 
service classes. 

• For both modalities and EasyVision workstations the 
patient management service class will be supported 
and provide a standard interface to RIS systems. An 
RIS-DICOM server will be available in order to inter- 
face with RIS systems that are not DICOM compat- 
ible. 

• DICOM media storage will be provided as soon as rel- 
evant standards are available (i.e., the completion of 
the parts 10, 11 and 12). Philips is actively involved in 
the standardization of an exchange medium for cardio- 
vascular image series in order to replace film in this 
application. 



• Relevant DICOM functionality for communicating im- 
ages in radiation therapy and treatment planning will 
become available soon. Philips is trying to find support 
to extend DICOM to patient-related treatment infor- 
mation. 

• The Philips PACS strategy is based on partnership 
with other vendors of the network services and the 
mutual validation of the DICOM services. This applies 
especially to archive vendors. Philips intends to have 
cooperation agreements with a few archive vendors in 
order to offer validated DICOM-based services be- 
tween our modalities, workstations, and archives. 

CONCLUSION 

Philips Medical Systems is committed to provide DICOM 
interfaces in all relevant areas for images as well as patient 
management. Philips will continue to support the improve- 
ment, enhancement, and maintenance of the standard and 
will be participating in various DICOM working groups for 
further extension of DICOM functionality and to improve 
image quality in print management and to enable lossy com- 
pression. 

Philips Medical Systems 

EO. Box 10,000 • 5680 DA Best, The Netherlands 



Picker is committed to meeting the increasing demands of 
the health-care industry by offering networking and connec- 
tivity services which meet user requirements in a cost-effec- 
tive fashion. DICOM plays a central role in such connectiv- 
ity. Connectivity provides many benefits, including distribu- 
tion of images within a single facility and to other facilities, 
off-line analysis, operational and data integration of imaging 
facilities with hospital information systems, and efficient use 
of capital equipment such as archiving systems and hard- 
copy devices. Picker is committed to providing open connec- 
tivity via DICOM, enabling extensive networks comprised 
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of Picker and third-party equipment Picker assists custom- 
ers in the design, installation, and servicing of such networks. 

Picker has provided leadership in the development of 
DICOM standards, including DICOM 3.0, by its active par- 
ticipation in ACR-NEMA and various DICOM committees 
for many years. Picker participated in the infoRAD demon- 
strations during RSNA '92 and '93 and is participating in this 
year's RSNA demonstration of DICOM. All Picker acquisi- 
tion systems and workstations offer DICOM 3.0 capabilities, 
presently available and installed in the field. These products 
include our line of CT scanners (IQ, IQ-Premier, PQS, PQ- 
CX and PQ-2000 systems), MR imagers (Merit, Vista, HPQ, 
Edge, and Asset), nuclear medicine systems (Odyssey & 
Prism), and x-ray devices (DSS and VMAX). All acquisition 
systems provide manual and/or automated export capabili- 
ties. All workstations provide query-and-retrieve, receive, 
and export capabilities. Active development continues in 
each of these product lines to provide additional functional- 
ity. 

For more specific information on product functions, please 
contact the sales specialist or marketing department associ- 
ated with that product, or call 1-800-323-0550. 

Picker has placed Conformance Statements for these 
products in the public domain, and these statements are 
available in hardcopy format through our marketing depart- 
ment or over the Internet. Internet access to our conform- 
ance statements can be gained by sending e-mail to Jay 
Gaeta (gaeta@picker.com). 

Picker DICOM 3.0 compliant products are already in- 
stalled in many institutions including: 

Perm State/Hershey Medical Center, Hershey, Pennsylvania 
Veterans Administration Baltimore, Baltimore, Maryland 
Mallinckrodt Institute of Radiology, St Louis, Missouri 
Hospital of the University of Pennsylvania, Philadelphia, PA 
University of Geneva, Switzerland 
MetroHealth Medical Center, Cleveland, Ohio 

Picker has an active program for validation of its products 
and Conformance Statements. Picker supports validation 
testing for interfaces to third-party systems. 



1. INTRODUCTION 

Based on its long experience in engineering diagnostic im- 
aging equipment, Siemens made a commitment to design 
and evaluate PACS systems from the very beginning and is 
now offering a PACS product family, called SIENET, indi- 
vidually configurable in a modular structured systems ar- 
chitecture (Figl) (1). 

Today, in addition, we know that medical professionals as 
well as hospital administrators can only gain advantages 
from the application-oriented improvements in PACS when 
the introduction of a PACS provides economical benefits for 
the institution, too. Without attempting to answer the still 
difficult question as to how to measure and prove the eco- 
nomic impact of any PACS installation, the cost efficiency 
of a PACS depends very much on its capability to inter- 
operate with currently installed and future imaging modali- 
ties from different manufacturers. Moreover, it has to allow 
the integration of image equipment (such as image work- 
stations, storage systems, and networks) purchased by the 
user from different manufacturers and to migrate into 
forthcoming technological solutions. In other words, a 
PACS will provide better economies when it is open to com- 
pete with and incorporate the best products from multiple 
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vendors. The key word for this highest priority user re- 
quirement is standardization. 

Therefore, it was an outstanding and successful activity 
when the American College of Radiology (ACR) and the 
National Electronics Manufacturers Association (NEMA) 
started in the early 1980s with the specification of the so- 
called ACR-NEMA digital imaging standard, which was 
published in 1985 as ACR-NEMA standards publication 
number 300-1985(2). 

As the scope of the ACR-NEMA standards publication 
number 300-1985 states, it was not the intention of the 
ACR-NEMA digital imaging working group at that time to 
specify an overall PACS or networking standard. In order 
to overcome this gap, Philips and Siemens started as a joint 
effort to work on the Standard Product Interconnect Speci- 
fication (SPI), which was published in December 1987 (3). 
Siemens made SPI an internal standard for its digital diag- 
nostic imaging modalities and implemented SPI into Si- 
emens' diagnostic imaging and PACS products, step by 
step. With the knowledge gained from its practical PACS 
installations (4) and the SPI development effort (3), 
Siemens can provide its customers with the advantage of a 
wide spectrum of standardized diagnostic imaging equip- 
ment today. These products do meet the image and header 
formats as defined by the ACR-NEMA digital imaging 
standards publication and are fully compatible with all 
SIENET products (i.e., with all Siemens PACS compo- 
nents). The principles of SPI have been well accepted, and 
some of them have been adopted by the various working 
groups of the ACR-NEMA committee or ACC/ACR- 
NEMA committee, respectively; they are being worked on 
in the next generation of standards for digital imaging and 
communications in medicine (DICOM). Work in progress on 
the developing DICOM standard was presented by several 
companies during the RSNA annual meetings in 1992 and 
1993. The new DICOM standard, at that stage, connected 
modalities to networks and defined functions for accessing 
and using these networks. 

Siemens has supported this process but could not avoid 



that the ultimate result was compatible with neither the 
former ACR-NEMA digital imaging standard version 2 nor 
with SPI. Nevertheless, Siemens prepared a migration 
strategy to make its products DICOM-compatible. Initial 
results were successfully demonstrated during the DICOM 
trialatRSNA'93. 

2. MIGRATION TO DICOM 

Siemens supported the idea of harmonization into an ACC/ 
ACR-NEMA standard from the very beginning and, there- 
fore, planned to migrate to DICOM, laying out two main re- 
quirements for such a migration already at a very early 
stage: first, to support the widely installed product palette 
with ACR-NEMA/SPI/PACSnet connectivity, and second, to 
provide a strong architectural platform for new product de- 
velopments. 

To meet these two requirements economically, a gateway 
between the world of DICOM and the established Siemens 
PACS environment together with a powerful DICOM 
toolkit to allow the successful development of new products 
were believed to constitute an efficient technical approach. 

The Siemens DICOM Architecture 

Due to Siemens far-reaching and extensive experience in 
digital imaging and networking within a medical infrastruc- 
ture, the goal was to create a proven concept for integrat- 
ing the installed base — without loss of information and 
performance — into the new concept of DICOM. Even in 
the initial product-definition phase, great importance has 
been attached to future compatibility and upgradeability in 
the ever-expanding and changing standardization process 
of image management and, in particular, of image manage- 
ment in medicine. 

Software tools are the building blocks of the Siemens 
DICOM architecture: 

• A format library to access and manipulate data struc- 
tures of both DICOM and ACR-NEMA/SPI image ob- 
jects; 



• A format converter to convert between different im- 
age formats being used in various installed or newly 
developed products; 

• A communication toolkit to establish and maintain 
communication between different users; 

• A set of services to communicate objects between ap- 
plications. 

A very important issue was the interchangeability of im- 
ages between existing (ACR-NEMA/SPI/PACSnet-based) 
and new (DICOM-based) products. Since DICOM intro- 
duces many new or changed modality-dependent attributes, 
this task was quite challenging. In order to catalogue and 
sort the requirements, Siemens introduced image conform- 
ance levels, not to be confused with the DICOM-defined 
Conformance Statement. 

Siemens will classify DICOM images according to the 
following conformance evels: 

Level 1: suitable for display (pixel and region of interest 
can be displayed) 

Level 2: suitable for simple evaluation (histograms, etc.) 

Level 3: suitable for reporting (image text [annotation] 
as patient, study, and measurement data can be dis- 
played in the same way as displayed with the originat- 
ing modality) 

Level 4: suitable for hardcopy output, including text 
Level 5: suitable for complex evaluation (3D, MPR, etc.) 

The introduction of conformance levels substantially im- 
proves readability of a Conformance Statement. This is 
very important. As the DICOM standard states: "This 
Standard facilitates interoperability of systems claiming 
conformance in a multivendor environment, but does not, 
by itself, guarantee interoperability." 

The extent to which interoperability can be expected be- 
tween two or more systems is given in the Conformance 
Statement. The quotation from another section of part 2 of 
the DICOM standard — "By comparing the Conformance 



Statement from different implementations, a knowledge- 
able user should be able to determine whether and to what 
extent communications might be supported between the 
two implementations." — clearly shows the importance of a 
Conformance Statement and the need for high readability. 

The DICOM Gateway 

Given the final publication of the DICOM standard by 
ACR-NEMA, the DICOM gateway will represent an imme- 
diate connection between the installed PACSnet/SIENET 

and DICOM products, based either on a TCP/IP or 79 
DECnet protocol stack. There are two solutions for a 
DICOM gateway: 

• The classical solution sees the DICOM gateway as an 
additional piece of hardware (dedicated gateway 
workstation) with a SIENET/PACSnet and a DICOM 
interface; 

• The integrated solution incorporates the gateway soft- 
ware as part of a PACSnet modality architecture (in- 
tegrated software solution). 



Figure 2 shows both possibilities. Depending on the re- 
quirements, the user will most likely choose one of the two 
solutions. The gateway will either run on top of a TCP/IP 
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or a DECnet protocol stack. 

With the DICOM gateway, Siemens created the basic 
component to migrate its modalities and SIENET products 
from the ACR-NEMA/SPI standard to DICOM. This 
means that the existing Siemens Protocol PACSnet is com- 
patible with our DICOM implementation in both directions. 
It also means that all equipment from other vendors com- 
plying to the de facto standard SPI or to DICOM can be 
connected to either a PACSnet environment or to a DICOM 
product In other words, wherever and whenever needed, 
Siemens can supply a DICOM-compatible Siemens modal- 
ity or a DICOM-compatible comprehensive SIENET net- 
work. In addition, selected modalities and SIENET compo- 
nents (as indicated above) can directly implement the 
DICOM gateway and will, therefore, represent an inte- 
grated DICOM interface. 

The DICOM Toolkit 

The major objectives for the design of the DICOM 
Toolkit were software quality and program safety. The 
DICOM Toolkit consists of a set of software tools to facili- 
tate the development of DICOM products. One highlight of 
the Toolkit is that its format library accesses ACR-NEMA 
and DICOM images with the same integrated data dictio- 
nary. Another aspect of the format library will be an on-line 
syntax checker for image validation. A semantics checker 
will be able to automatically provide a classification to a 
specific conformance level. Both "preprocessors" will en- 
hance quality and liability of the interface between two ap- 
plications. The format converter will provide a high quality 
of converted images from different format dialects by 
means of several ACR-NEMA, ACR-NEMA/SPI, and 
DICOM derivatives. The format converter will directly 
build upon the format library. 

Since DICOM images are more "complete" (i.e., in 
simple words, the DICOM data structure contains more at- 
tributes), mapping from ACR-NEMA/SPI to DICOM can 
only be implemented with the support of the modalities that 
produce the images. Therefore, the conformance level of 



Siemens images will generally be higher than that available 
from other vendors' sources. 

Other important parts of the DICOM Toolkit are the soft- 
ware tools for establishing communication and a common 
API for using the services (e.g., send, receive, and query- 
and-retrieve tools). In further developmental phases, the 
DICOM Tbolkit will also provide services for HIS-RIS inter- 
faces between modalities, PACS systems and, ultimately, be- 
tween health care information systems in general. 

3. OUTLOOK 

All the above-mentioned steps will lead to integrated 
DICOM systems from Siemens and other vendors of medical 
products. In parallel, Siemens will focus on a strategy for the 
future. 

Customer Requirements 

Digital imaging in general — not just medical imaging — 
and networking is still a very fast-growing technical field. In 
the near future, we expect a strong impact from multimedia 
needs. In this context, we are no longer in a pure medical 
environment, but have to deal with "medical objects" within 
a multimedia infrastructure. Today, we transmit medical im- 
ages with possible annotations consisting of text (patient 
name, reports, etc.) and graphics (ROIs, arrows, and so 
forth). 

Within a multimedia infrastructure, a medical image itself 
can be seen as an "annotation" of a multimedia hyperobject. 
Therefore, the demand for basing medical products on infor- 
mation technology (IT) platforms, plus added Medical at- 
tachments," will increase. 

ISO / IEC — Imaging 

ISO standard IPI (5), developed by a joint committee of 
ISO and IEC (ISO/IEC JTC 1 SC 24), can be used to define 
such a hyperstructure for a multimedia medical infra- 
structure mentioned above. 

Siemens anticipated this evolution in health care. There- 
fore, Siemens participates in the development of IPI with 



members of IT sections of the company, and the Siemens 
Medical Group is actively involved in the standardization of 
IPI. 

CEN TC 251 — Medical Informatics 

In close cooperation between vendors, users, and other 
standardization organizations (such as ISO, IEC or ANSI 
and JIRA), CEN TC 251 (the European Standardization 
Body) will create an evolution process and a migration 
strategy to reach the goal for open communication in medi- 
cine within this multimedia infrastructure. 

Migration Strategy toward IT 

Figure 3 shows the basic strategy of CEN TC 251. To 
guarantee upward compatibility to satisfy both vendors and 
users, CEN begins by adopting DICOM as a starting point 
for migration. In order to distinguish the activity of CEN 
from previous work by ACC, ACR, NEMA, and others, and 
also to show its origin, the "new" standard will be called 
MEDICOM (MEDical Image COMmunication), but 
MEDICOM could also be interpreted as "Multimedia Ex- 
tended DICOM." 

The first important step will be to establish a "registra- 
tion authority" supported by the European Union and In- 
dustry to implement necessary updates to the standard in a 
safe, coordinated and documented way. 

Slowly, MEDICOM will migrate toward an IT platform 
with the full support of Siemens. Step 2 will allow a transla- 
tion of a DICOM-encoded image into an IIF-encoded (IIF 
[Image Interchange Facility] is part 3 of IPI) image, thus 
allowing any application direct access to an IT-IPI-PIKS 
implementation. (PIKS [programmer's imaging kernel sys- 
tem] is part 2 of IPI.) Step 3 will integrate this process into 
the MEDICOM object itself. Finally, step 4 will represent 
the above-mentioned hyperobject. All steps are based on 
the assumption that IPI will be broadly accepted by the in- 
formation technology industry. 
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4. The Concept — There Is a Tomorrow 

Siemens set up the following simple rules to reduce costs 
for developing software and increase benefits for the user 
(which also means reducing costs in providing health care): 

• use existing software; 

• reuse software already written; 

• thorough software quality and software design 
to system safety. 

Examples of existing software include operating sys- 
tems, prototyping tools for designing user interfaces, tools 
for network access (e.g., ftp, CORBA [6], or, most impor- 
tant, software based on "standards" from the Information 
technology world like MIT's XI 1 or IPI, particularly imple- 
mentations of PIKS for image processing or ASN.l [7] 
parsers and generators for IPI-IIF data structures). Reus- 
ing software is an in-house process of structuring software 
development. A common software architecture builds the 
platform for modalities and PACS development to reuse 
software written in a "central" software team. Through 
stepwise introduction of object-oriented methodology and 
by building and maintaining object-oriented class libraries, 



the probability of reusing "software packages" will drasti- 
cally increase. 

As in the past, Siemens will also prove in future that a 
sound system design together with emphasis on software 
safety will lead to high-quality products. Quality is the bot- 
tom line. 
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DeJarnette Research Systems Inc. (DRS) offers several 
products applicable for the implementation of DICOM 3.0 . 
The company has offered ACR-NEMA interfacing to imag- 
ing systems and other PACS components of various ven- 
dors. More recently, DRS has supplied interfacing equip- 
ment and services to the Medical Diagnostic Imaging Sup- 
port project of the U.S. Army and has installed a major 
PACS system at the Baltimore Veterans Administration 
Medical Center. 
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SOFTWARE PRODUCTS 
Introduction 

DeJarnette Research Systems provides DICOM support 
to application developers with a series of software products. 
One of these products is the AN/API developer's toolkit. 
The AN/API provides the communication protocol, remov- 
able media support and message encoding required of a 
DICOM-conformant application. DICOM associations are 
requested and accepted as defined in DICOM parts 8 and 9. 
Removable media support adheres the rules specified in 
DICOM part 10. Messages are encoded in accordance with 
DICOM parts 5-7. The AN/API can therefore support all 
of the DICOM service-object pair (SOP) classes defined by 
DICOM parts 3 and 4. 

Supported Platforms 

The AN/API is available for many platforms and operat- 
ing systems. AN/API libraries operate on any 16-, 32-, or 
64-bit big or little endian processor. The AN/API automati- 
cally handles the byte ordering of the attributes when it 
sends or receives the DICOM message. 

Most of today's major operating systems are supported 
by the AN/API. The list, however, is never complete. The 
AN/API continues to be ported to new operating systems 
as those systems become available for widespread use. The 
following operating systems are available today. 



PC Operating Systems 
Microsoft DOS 
Microsoft Windows 
Windows NT 
OS/2 

Unix Operating Systems 
SunOS 
Solaris 
OSF 

Silicon Graphics IRIX 

Hewlett-Packard HPUX 
Macintosh 

System 7 
Embedded Operating Systems 

VRTX 

pSOS 



The AN/API can use any file system when reading or 
writing DICOM messages from or to disk. The file system 
may be local or remote, permanent or removable. On sys- 
tems that have limited memory resources, the AN/API en- 
ables the application to use the disk as an alternate memory 
source. 

Memory requirements for the AN/API library routines 
are minimal. The AN/API has optional library modules that 
may or may not be required by the application. If the mod- 
ule is not necessary, the corresponding library does not 
need to be linked into the application. The library's memory 
requirements varies according to the platform and operat- 
ing system but typically requires 30 Kbyte of memory. 

Operating systems that support dynamic libraries 
(DLLs, threads, etc.) can share memory resources by using 
the AN/API'S dynamic linked libraries. 

The AN/API supports the DICOM upper layer protocol 
(part 8) over TCP/IP and Decnet. The AN/API makes use 
of the system's native services. It supports Berkeley 
socket, Microsoft WinSock, and MacTCP programmer's in- 
terfaces for TCP/IP DEC's network interface, Berkeley 
sockets, and Sun Microsystem's DNI interfaces are the 



supported Decnet programmer's interfaces. Any media 
supported by the communication services of the operating 
system can be used by the AN/API. This includes 
Ethernet, FDDI, T1/T3, ATM, and standard phone lines. 

The AN/API also supports the DICOM point-to-point 
communication protocol (part 9) with De Jarnette Research 
System's ANSIF driver and AT/ANSIF-HP interface 
board. 

Installation 

The AN/API consists of a set of linkable libraries and 
two data files. One of the data files contains all of the 
DICOM UIDs used for establishing associations with re- 
mote application entities. The other data file contains the 
supported data dictionary. Each of these files may be up- 
dated by the user as the DICOM standard evolves to in- 
clude new SOP classes and attributes. 

Installing the AN/API involves copying the libraries and 
data files to the development system. The AN/API is avail- 
able on floppy disk and cartridge tape. Once installed, the 
AN/API is ready to use. 

Included on the AN/API distribution media are a test 
application and sample client and server source code. The 
test application can be used to validate any of the AN/API 
functions. The sample source code shows how the AN/API 
can be used to build and parse DICOM messages as well as 
how to establish DICOM associations and transmit and re- 
ceive those messages. The source code may be compiled 
and executed by the developer in order to test the library 
functions. 

Software Functionality 

The AN/API is an application developer's library. The 
application determines the peer with which it needs to com- 
municate and calls AN/API functions to establish connec- 
tions. Similarly, when a message needs to be generated, the 
application determines the information that is to be in- 
cluded in the message and calls AN/API functions that en- 
code the information. When parsing a message, the applica- 



tion requests the desired information and the AN/API re- 
trieves it from the message. 

Initialization and Configuration. — When the AN/API 
initializes, it defaults to a DICOM conformant configura- 
tion. The application developer has the ability to modify the 
configuration on various levels to better service the applica- 
tion. A modified configuration can be applied to the entire 
application, a single association, or a single DICOM data 
set. The AN/APFs configuration can be modified to provide 
support for older versions of the ACR-NEMA standards 
and for other ACR-NEMA-like standards. 

In addition to standard-related configuration param- 
eters, the AN/API supports the modification of some run- 
time parameters. The application can configure the AN/ 
API to suit the platform on which it will run, thereby opti- 
mizing its use of system resources and features. 

DICOM Associations. — A DICOM association exists on 
top of an open protocol connection. The AN/API, after es- 
tablishing the protocol connection, negotiates the DICOM 
association. The information used during the negotiation 
procedure is specified by the application. 

When waiting for DICOM association requests from re- 
mote application entities, an application specifies the appli- 
cation context, including supported presentation contexts 
and user information, that it will accept. The AN/API, after 
detecting a request for an association,negotiates the asso- 
ciation parameters by validating the requested context 
against the specified application context. If there is a match 
between the contexts, the association is accepted. Failure to 
match the requested context with the application-specified 
context causes the AN/API to refuse the association. When 
an association has been successfiiUy negotiated, the AN/ 
API returns to the application a handle to the association. 
The application is, at that point, able to send and receive 
DICOM data sets over the association. 

Similarly, an application that wishes to request an asso- 
ciation to a remote entity specifies the application context, 
including the requested presentation contexts and user in- 
formation, to the AN/API. This information is used to build 



and send an association request to the specified application 
entity. The result of the association negotiation is returned 
to the application. If the remote entity accepted the asso- 
ciation, DICOM data sets may be sent and received over 
the new association. 

DICOM associations may be released and aborted by the 
application entity. By making an AN/API function call, the 
association is terminated according to the rules of the 
DICOM standard. 

DICOM Data Sets. — The most extensive part of the 
AN/API toolkit is its support for data-set encoding. The 
AN/API provides routines to build and parse DICOM data 
sets in addition to routines that can be used to provide the 
information necessary to identify DICOM attributes. The 
AN/API handles both implicit and explicit value represen- 
tations (VRs). Coupled with its ability to support big and 
little endian encoding, the AN/API supports all of the de- 
fined transfer syntaxes. 

The AN/API provides the application with the proper en- 
coding for Command and Data data sets. Group length ele- 
ments, when required or when configured to be inserted, 
are calculated by the AN/API. 

The AN/API enables the application to perform the fol- 
lowing data-set functions: 

insert an attribute 
retrieve an attribute 
retrieve the next attribute 

position the AN/API at a specific location in a message 

rewind the message 

link the message to a disk file 

append a Command data set to a Data data set 

resolve an attributes VR 

Error Handling and Debug Capabilities. — The AN/ 
API supplies a variety of error codes that identify anoma- 
lous situations. The AN/API handles errors by cleaning up 
any residual effects of the condition and returning the asso- 
ciated error. Certain error conditions, such as detected pro- 



tocol violations, result in an automatic response as defined 
in the DICOM standard. The application does not need to 
handle such conditions itself. 

Debug in the AN/API is extensive. The AN/API supplies 
run-time diagnostics that may be turned on and off at any 
time by the application. The AN/API can be configured to 
report error conditions and/or status messages. Error mes- 
sages may contain the system error code, if available. Sta- 
tus messages contain information that indicates the current 
operation the AN/API is performing along with information 
about the operation. For example, AN/API status debug 
will print the contents of association request and response 
PDUs received when attempting to establish an association. 

Diagnostic messages are directed to a routine that pro- 
cesses them. By default, this routine prints the messages to 
the standard error device. The application has the ability to 
specify its own diagnostic processing function. This capabil- 
ity enables diagnostic messages to be logged in a manner 
suitable to the platform on which the application is running. 
For example, the diagnostic messages can be directed to a 
status window on a windowing system. 

Product Support 

The AN/API is supported by De Jarnette Research Sys- 
tems' customer support department. Questions concerning 
installation, usage, and behavior of the AN/API are ac- 
cepted. Support is provided over the phone by dialing (410) 
583-0680 and electronically by sending e-mail to 
support@dejarnette.com. 

SYSTEMS 
Imageshare 910 

These are gateway systems capable of converting full 12- 
bit digital outputs of various imaging systems into standard 
format (DICOM 3.0. and earlier versions ACR/NEMA 2.0) 
The outputs are compatible with LANs and WANs. Specifi- 
cally, the following systems can be interfaced : 



GE CT 9800 Quick 
CT 9800 HTD 
9800 Hilight Advantage 
Hilight Advantage 
HiSpeed Advantage 
Pace Model (1994) 



MR Signa Advantage 5.x 
MR Signa Advantage 4.x 
Advantage DX 

GE Adv. Independent Console 
CT 9800 Independent Console 
Advantage Windows Workstations 



Siemens 



Somatom 
Magnetom 
Impact MR 



Litebox 

DVC, DRC Workstations 

ISA Archive 

ECAT 



Philips 
Picker 



CT LX, TX, CX 



PQ2000 CT 
1200SX CT 
Odyssey Nuclear 



Toshiba 



MR Vista 

Vistar Workstation 

MR Edge 

MR Asset 

MR 2050 

MR HP 



Access MR 



FVgi 



AC1 
AC 2 
AC 3 



9000 



Film Digitizers 

Lumisys 100,150,200 



Display and Workstations "Teleshare 910" 

These products comprise single-monitor high-resolution 
teleradiology displays, a dual-monitor high-resolution dis- 
play with ISDN interface, and JPEG compression as well 
as a group of network-ready, DICOM-compatible worksta- 
tions. 

Lasershare 910 

The Lasershare is a DeJarnette Research Systems 
PACSware system. PACSware systems are designed so 



that they can operate on a number of independent plat- 
forms. The Lasershare is a modular system that uses net- 
work interfaces for communication between the modules, 
which can reside locally or remotely. The primary Laser- 
share modules are the Laser Spooler, Image Acquisition 
Server, and Printer Formatter. Other modules are Configu- 
ration and Debug modules. 

The Spooler module is the control center of the 
Lasershare and is responsible for the system management, 
communication control, sheet generation and management 
(including printing), orphan control, and recovery manage- 
ment. System management maintains information about its 
resident Formatters in addition to information about other 
Spoolers and Formatters connected to the network. All 
communication between Servers, Formatters, and other 
Spoolers goes through the Spooler module. 

The Server module is responsible for acquiring the im- 
age data and presenting the film information to the Spooler. 
This may require that the Server operate as a filming sta- 
tion. Its output is used by the Spooler to generate a sheet of 
film (such as the number of images, LUT's location of im- 
ages on the film, annotation and overlays, etc.). Each server 
implements a single acquisition protocol. The Lasershare 
supports many server modules. 

Each Formatter modules services a single printer. A 
Formatter is responsible for taking the sheet information 
generated by the Spooler and converting it into a format 
understood by the serviced printer. Each Formatter under- 
stands only one printer protocol. A Lasershare supports 
many Formatters. 

The Lasershare provides Server modules for the follow- 
ing acquisition interfaces : 

DICOM Print Management SOP 

DICOM Point-to-Point Print Management SOP 

DICOM Storage Class SOP 

Video FVame grabbers 

Siemens SPCI/SPDI camera interface 

3M Laser Imager (P831) and Laser Imager Plus (M952) 



KODAK EKTASCAN Laser Printer (KELP) 
Polaroid Helios 810 Laser Imager and 14 x 17 Image 

Manager Lpr 
Agfa Medical Digital Interface (AMDI) 
Analogic DASM interface 
PACSNET message storage 

The Lasershare provides Formatter modules for the fol- 
lowing printer interfaces: 

DICOM Print Management SOP Class 93 
DICOM Point-to-Point Print Management SOP Class 
Siemens SPCI/SPDI camera 

3M Laser Imager (P831) and Laser Imager Plus (M952) 
KODAK EKTASCAN Laser Printer (KELP) 
Polaroid Helios 810 Laser Imager and 14 x 17 Image 

Manager Lpr 
Agfa Medical Digital Interface ( AMDI) 
Analogic DASM interface 
Seike thermal dye sublimation printer 
Harris Photo Pro 2000 



SMALL-PLATFORM IMPLEMENTATION: 

PC & MACINTOSH 

Overview 

Implementation of DICOM on small computer platforms in- 
volves challenges mostly related to the power of (resources 
available to) the operating system rather than processor ca- 
pability per se. For the purpose of this discussion, PC-DOS, 
Mac System 7, and Windows 3.1 are the operating systems 
being considered. (There are a number of commercially sup- 
ported UNIX implementations available for PC platforms 
that do not suffer from the same limitations of DOS, Win- 
dows, and Mac System 7. Windows NT [Microsoft] and OS/2 
[IBM] are not considered herein, either, because they also 
can support resource-rich environments.) 



Merge 

Technologies 
Inc. 

W Stafford 



HARDWARE AND SOFTWARE REQUIREMENTS 

For a PC-DOS implementation, an 80286 central processing 
unit (CPU) with 1 MByte of memory and a Winchester disk 
are the minimum requirements. A faster processer and 
more memory can be utilized with good effect. PC-DOS 3.3 
or higher and FTP's PC/TCP are required, the latter for 
provision of TCP/IP services that use a Berkeley Sockets in- 
terface. 

For a Windows 3.1 implementation, an 80386 CPU with 4 
MByte of memory and a Winchester disk are required. 
More memory and a faster processor result in less impact 
on other applications running concurrently. 

On a Macintosh running System 7, best results are 
achieved with a 68040 CPU, although a 68030 CPU with a 
clock speed of 33 MHz can be utilized. MacTCP is required 
to provide the TCP/IP underpinnings and a Berkeley Sock- 
ets interface. 

Supported DICOM Services. — DICOM implementation 
on small platforms has encompassed principally the storage 
service class of DICOM. These implementations have per- 
mitted acceptance and transmission of DICOM image ob- 
jects by workstations (e.g., for use in image review or 
therapy planning), archival devices, and protocol convert- 
ers. 

DICOM Implementation Support. — Please see the fol- 
lowing chapter on product information for specific informa- 
tion on support by Merge Technologies Inc (Merge) for 
both small- and large-platform implementations of DICOM- 
conformant applications. 

PRODUCT INFORMATION 
Overview 

Merge develops and markets hardware and software de- 
signed to facilitate communication of diagnostic images over 
standard Ethernet networks. 

Product Line 

Merge's products can be likened to complementary 
"building blocks." The product line consists of: 



1. Software "Tool Kits" designed for use on a variety of 
computer platforms: 



MergeCOM for implementing peer-to- 

peer image message handling 
and communications in ACR- 
NEMA version 2.0 format over 
TCP/IP Ethernet 



MergeCOM-3 for implementing DICOM 3.0- 
conformant image message 
handling and communication 
within applications 



Please see Exhibit 1 for a list of supported platforms and 
operating systems. 



2. Hardware products that are self-contained devices 
composed of hardware and Merge proprietary soft- 
ware: 



MergeMVP a family of standalone interfaces, 

each of which converts a particu- 
lar imaging device's proprietary 
protocol to an open Merge proto- 
col or another proprietary proto- 
col 



MergeLFM a network print server for laser 

imagers that accept MergeCOM 
or MergeCOM-3 (DICOM) print 
messages 



Please see Exhibit 2 for a MergeMVP connectivity list- 
ing. 

Merge image communication products allow "closed" 
systems, such as imaging devices, workstations, laser film 
printers, and even complete networks to become "open" 
and compatible with other imaging devices or networks. 



Key to Merge's products are technology agreements 
Merge has in place with major imaging vendors, allowing 
Merge access to their proprietary protocols and formats. 
Under these agreements, OEMs have supplied Merge with 
the information required to create these products and the 
testing opportunities necessary for functional validation. 

SOFTWARE PRODUCTS 

Merge software products are based on industry-standard 
file formats and communications protocols developed by the 
ACR-NEMA collaborations. In addition to using these soft- 
ware components in Merge's own product line, Merge also 
provides Integrator's Tbol Kits and Run-Time Licenses for 
system developers who wish to take advantage of Merge's 
connectivity experience. 

ACR-NEMA 2.0 Software 

MergeCOM is Merge's ACR-NEMA 2.0 communication 
tool. MergeCOM puts the industry's first standard image 
communication format onto TCP/IP Ethernet implemented 
in a peer-to-peer environment for point-to-point or network 
communications. 

DICOM 3.0 Software 

MergeCOM-3 is Merge's newest communication tool. 
MergeCOM-3 facilitates fully conformant implementation 
of the DICOM 3.0 standard. It is a significant technological 
advance over its predecessor, MergeCOM, but continues 
MergeCOM's role as the foundation of Merge Technologies' 
cross-vendor, open-systems connectivity strategy. 

MergeCOM-3 embodies the industry-standard data for- 
mat and communications protocol, DICOM 3.0. Connections 
can be as simple as point-to-point (between two devices) or 
as complex as a multmodality network of multiple devices. 
Used in conjunction with Merge's family of MergeMVP in- 
terfaces, MergeCOM-3 and related development tools can 
provide an environment of "open communications" between 
any and all of the imaging devices and peripherals in an im- 
aging department. 



The MergeCOM-3 Basic Integrator's Tool Kit pro- 
vides the most fundamental DICOM capabilities and is de- 
signed to provide an easy upgrade implementation for cur- 
rent MergeCOM users. Basic MergeCOM-3 supports 
DICOM's storage service class (image transmission be- 
tween devices). 

The MergeCOM-3 Advanced Integrator's Tool Kit in- 
troduces a new API and supports all of the DICOM 3.0 ser- 
vice classes, including the storage service and: 

• Query/Retrieve Service Class 

(a means of looking into another DICOM-conformant 
device and retrieving data); 

• Basic and Advanced Print Service Classes 

(a means of formatting and sending image data to net- 
worked DICOM-conformant hardcopy systems); and 

• HIS/RIS Service Class 

(a means of connecting to and exchanging demo- 
graphic, scheduling, and other such data with 
DICOM-conformant information systems). 

An overview of the Advanced Tool Kit follows this discus- 
sion as Exhibit 3. Tool Kit is user-friendly, supplying not 
only global defaults but a template-building capability for 
creating DICOM messages. Protocol data units are gener- 
ated for the developer from a Merge-supplied table of pre- 
sentation data values organized by SOP and DIMSE ser- 
vices. Extensive error detection and correction are enabled 
both with a "Validate" function, which validates the 
message's Type 1 and Type 2 elements against the stan- 
dard, and with extensive communications and protocol de- 
bugging facilitated with detail configurable logging, useful 
both in validation of one's own development and also in vali- 
dation with other implementations. 

HARDWARE 

Merge has developed a line of standalone 'Interfaces" and 
network "servers" that provide connectivity solutions to 
OEM's and end users. These hardware systems utilize 



Merge software products in the internal data and communi- 
cations conversions and depend on a close cooperation and 
with major imaging device manufacturers to affect connec- 
tivity to both imaging devices and image peripherals. 

Protocol Converters 

The MergeMVP (Multi-Vendor Protocol Converter) pro- 
vides a means to connect a proprietary image producing de- 
vice ("scanner") with other image-using devices or with a 
network. The "input to the MergeMVP" is an internal 
"module" that consists of hardware and Merge-proprietary 
software specific to the "personality" of the scanner. "Inside 
the MergeMVP" software converts the "closed" image in- 
formation from the scanner into a uniform "open" format 
such as MergeCOM (ACR-NEMA 2.0) or MergeCOM-3 
(DICOM 3.0). The "output of the MergeMVP" can be con- 
figured via an internal hardware andsoftware module with 
the "personality" of one of the standard Merge outputs 
(MergeCOM or MergeCOM-3) or proprietary output suit- 
able for another vendor's image-using device or the net- 
work to which connection is being made. 

The architecture of the MergeMVP allows Merge to ac- 
commodate diverse connection requirements by means of 
different combinations of Merge-developed modules. As an 
example, input modules currently available from Merge are 
shown in Exhibit 2. Additional modules will be added as 
market demand dictates. 

Network Servers 

The MergeLPM (Laser Filming Manager) receives im- 
age files from multiple image sources and executes pre-de- 
fined applications such as transferral of print jobs to laser 
imagers or paper printers. It enables the sharing of 
hardcopy devices by multiple image-producing or image-us- 
ing devices across a standard Ethernet network. 



PRODUCT SUPPORT 

In addition to providing software and hardware and full 
support for these products, Merge also provides consulting 
and system integration services. 

Consulting and Systems Integration 

Merge provides a variety of services under a consulting 
umbrella called MergeLINK. The consulting program is 
provided to individual hospitals, health maintenance organi- 
zations, and imaging vendors that seek guidance in either 
planning for a future imaging network or actually building 
that network. 

MergeLink consists of: 

1. Sale of consulting on a time and expense basis, includ- 
ing researching the requirements to meet the user's 
expectations and applications (working with all ven- 
dors involved). 

2. Provision of custom interfacing, if necessary. 

3. Sale of system integration and installation on site (in- 
cluding location and subcontracting of local network 
cabling services). 

Service and Support 

Merge provides warranty and after-warranty service for 
both software and hardware products. Software revisions 
consisting of bug fixes and accommodations of vendor's 
software changes (vendor changes that affect interfacing or 
functionality) are provided free. Hardware products are 
warranted for 1 full year and repaired or replaced at the 
factory. 

On-site trouble-shooting and service of Merge hardware 
products (MVP and LFM) is provided through modem 



communication with the individual product or network of 




products. Merge provides on-site service and follow-up un- 
der contract with third-party service organizations, 

EXHIBIT 1 




DOS -PC 

System 7 — Macintosh 
UNIX 

Hewlett Packard 
Silicon Graphics 

Digital Equipment Corp. — Alpha 
Sun OS 4.1.3 
Sun Solaris 2.3 
PC - BSD386 
IBM RS 6000 - AIX 
Convergent 
VMS -VAX 

MergeCOM-3 Basic: 

DOS — PC 
System 7 — MAC 
UNIX 

Hewlett Packard 
Silicon Graphics 
Sun OS 4.1.3 
Sun Solaris 2.3 
PC — BSD386 
IBM RS 0000 — AIX 
PC — QNX 
VMS — VAX (in process) 

MergeCOM-3 Advanced: 

DOS — PC 
UNIX 

Hewlett Packard 
Sun OS 4.1.3 
Others to follow 




EXHIBIT 2 

Imaging System Connectivity 
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manufacturer 


Ma rial 

model 


Merge Product Modality Requirement 


M0TUS 


Elscint 


CT Elite 


MVP-TE 


Tape Drive 






In Process 








CT Elite 


MVP 


Ethernet 


Planned 




CR AC1, AC2 


MVP 


SCSI 


Planned 


General 


CT 8800 <DG) 


MVP-TE 


Tape Drive 




Electric 


Installed 








CT 9800 (DG) 


MVP-TE 


Tape Drive 






Installed 










MVP-TE 


Tape Drive 






Installed 












MVP 


ID/Net v2.0 
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MR Signa (Sun) 


MVP 


ID/Net v2.0 


Installed 




CT Pace 


MVP 


Ethernet 


Planned 




MR MAX 


MVP 


Ethernet 


Planned 


Hitachi 


MR-5000 


MVP 


GPIB 


Installed 




MR-7000 


MVP 


SCSI 


Installed 




CT W1000 


MVP 


GPIB 


Installed 




CT W 9 000 


MVP 


SCSI 


Instill led 


I matron 


CT 


MVP 


GPIB 


Planned 


Philips 


Philips PACS 


MVP 


DR-11W 


Installed 


CX TX LX 


MVP 


GPIB 


Installed 




CT310, 350 


MVP-TE 


Tape Drive 


Planned 




CT SR 


MVP 


SCSI 


Installed 




MR S-15, T-5 
DSI 


MVP 


GyroCom 


Installed 




MVP-LP 


Laser Camera Port 


Installed 




GyroView 


MVP 


GyroCom 


Installed 


Picker 


Q-Series CT 


MVP 


Ethernet 


Installed 




Vista MR 


MVP 


Ethernet 


In Process 


Kesonex 


RS4000 


MVP 


Ethernet 


Installed 


Siemens 


CTCR, DR 


MVP 


CT/MR Net 


Installed 




CT Somatom 


MVP 


PACSnet 


Installed 




Plus, Hi-Q 










MR Magnetom 


MVP 


CT/MR Net 


Installed 




MR Magnetom SP 


MVP 




PACSnet 












Installed 










MR SP/4000 


MVP 


PACSnet 


Installed 




MR Impact 


MVP 


PACSnet 


Installed 




LiteBox 


MVP 


PACSnet 


Installed 




Polytron 


MVP-LP 


Laser Camera Port 


In Process 


Toshiba 


TCT 600 


MVP 


DR-11W/TDIS 


Installed 




TCT 900 


MVP 


DR-11W/TDIS 


Installed 




Xpress 


MVP 


Ethernet 




Planned 












MRT 50,150 


MVP 


DR-11W7TDIS 


Installed 




DFP 50,60 


MVP 


DR-11W/TDIS 


Installed 



EXHIBIT 3 

MergeCOM-3 Advanced Integrator's Tool Kit 
An Overview 

The MergeCOM-3 Advanced Integrator's Tool Kit (Ad- 
vanced Tool Kit) completes the evolution of the MergeCOM 
family of software to full support of the DICOM 3.0 stan- 
dard. The Advanced Tool Kit is a cross-platform, scalable, 
simplified DICOM 3.0 solution for medical imaging applica- 
tion developers. In its initial release, the toolkit supports 
echo, storage, query/retrieve, and basic print services. 
Soon to follow are HIS/RIS and advanced print services. 
This document summarizes key features and design points 
of the Advanced Tool Kit. 

Advanced Tool Kit Components 

The Advanced Tool Kit consists of the following compo- 
nents (Fig 1): 

1. A function library specific to the computer platform 
that is linked into the application being developed and 
supplies MergeCOM-3 Advanced Application Pro- 
gramming Interface to DICOM. This library does al- 
most all of the "DICOM work." 

2. Four user-editable configuration files; 

1. MERGE.INI Merge Initialization File 
Identifies product parameters, such as error log- 
ging parameters that specify the desired detail and 
location of error logging. 

2. MERGECOM.SYS System Profile 
Contains system and network parameters for the 
application(s) being developed; these parameters in- 
clude supported transfer syntax, listen port, and 
network time-outs. 

3. MERGECOM.APP Application Profile 

For each remote DICOM application, this profile 
contains that application's title, host port and name, 
and a list of services that application requires or 
supports. 

4. MERGECOM.SRV Merge Service Profile 



Contains a list of DICOM services the application sup- 
ports. Only those standard services being supported need 
to be included. 

3. A message object database in the form of binary files 
that describe the DICOM objects which the 
application(s) will communicate over the network. 
The code library uses this database at runtime to con- 
struct, maintain, and validate the instances of DICOM 
message objects that the application populates with 
data. The library then manages the exchange of these 
messages with other DICOM applications over the 
network. 

4. A data dictionary, which is a binary file that contains a 
data dictionary of all DICOM attributes and their re- 
spective data types. This file is also used by the code 
library for the proper formatting and validation of 
messages. 

For developers who need to extend DICOM by defining 
their own private services (SOP classes) and message ob- 
jects, Merge will supply a Microsoft Windows-compatible 
database application that facilitates extension of the stan- 
dard DICOM information objects and SOP classes with pri- 
vate attributes or definition of private SOP classes. In- 
cluded with this database are applications that generate the 
run-time binary message object database and data dictio- 
nary files. 

KEY FEATURES 
Scalability 

The Advanced Tool Kit is highly configurable to better 
utilize resource-rich systems (such as UNIX workstations) 
while not ruling out lower-end platforms (e.g., DOS or Win- 
dows). For example: 



1. The message object database and data dictionary can 
be read into memory at application startup or read 



from the file system on an as-needed basis. 

2. As large data attributes (such as pixel data values and 
overlays) arrive or depart over the network, they can 
be throttled directly by the application a "chunk" at a 
time through callback functions specified by the devel- 
oper. If a callback mechanism is not specified, the 
toolkit stores the large data automatically, either in 
memory or temporary files (configurable). 

3. The runtime message object database need only con- 
tain the objects for the DICOM services your applica- 
tion requires. This means that highly specialized ap- 
plications can run with the smallest possible message 
object database in primary memory. 

Flexibility 

If the DICOM 3.0 standard does not supply services 
(SOP classes) specific enough to a developer's needs, the 
standard message object database and data dictionary can 
be extended to support private attributes directly through 
the API at runtime. If private SOP classes that differ sig- 
nificantly from any of the DICOM standard SOPs are re- 
quired, Merge provides a message object database mainte- 
nance application for Windows to facilitate creation of the 
needed special runtime message object database. 

Simplicity 

The Advanced Tool Kit API is powerful yet simple: 

1. Register the application with the Tool Kit library us- 
ing 

MC_Register_Application( ). 

2. As a client, open a connection with a DICOM server 
with 

MC_Open_Association( ) 
or, as a server, wait for a connection from a DICOM 
client with 

MC_Wait_For_Association( ). 



3. Create a DICOM message object with 

MC_OpenJMessage( ). 

4. Fill in the message object using the MC_Set_Value( ) 
family of functions. 

5. Parse a message object using the MC_Get_Value( ) 
family of functions. 

6. Send messages over the association that has been 
opened with 

MC_Send_Message( ) 
and wait for messages with 
MC_Read_Message( ). 

7. Validate a message constructed or received by the ap- 
plication against the DICOM standard or private ser- 
vice definitions with 

MC_Validate_Message( ). 

8. Declare callback functions, define private attributes, 
stream DICOM messages to and from message ob- 
jects, and so on with other Advanced Tool Kit func- 
tions. 

Portability 

The Advanced Tool Kit is object-oriented in design and 
written in ansi-c to maximize portability and performance. 
The earliest releases are for POSIX/UNIX and DOS plat- 
forms. Ports to Windows, Windows NX OS/2, and the 
Macintosh will be available in the near future. Other ports 
will be accomplished based on demand and require only 
that the platform support an ansi-c compiler and a Berke- 
ley Sockets (or WinSock) interface to TCP/IE 

The Advanced Tool Kit is designed so that moving to 
transport layers other than TCP/IP and Sockets (e.g., 
Streams or TLI) can be accomplished in a straightforward 
manner as requirements arise. 



CHAPTER 5 
Appendices 



A. Glossary 
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Abstract syntax generic term, by DICOM 3.0 implemented 
as SOP syntax 

ACR American College of Radiology 

Access protocol traffic rules to establish association and 
avoid collision 

ACSE Association Control Service Element used to estab- 
lish an association 

ANSI American National Standards Institute 

Application context identifies the overall communication 
context 

Application entity (AE) a DICOM-conformant agent on 
the network 

Association a network connection 
Attribute a property of an item 
Byte ordering see Endian 

CEN TC 251 Comite Europeen de Normalisation Technical 
Committee 251 

Client server network terms for specific roles, equivalent to 
SCU and SCP 

Command information item requesting an action 



Composite object representing more than one real-world 
object 

Conformance Statement part 2 of the DICOM standard 
specifying performance 

Data dictionary part 6 of the DICOM standard 

Data element a subunit of an information object 

DIMSE DICOM Message Service Elements, functionality 
capable of generating type 4 PDUs 

Domain an Internet zone of authority, part of the address 
structure 

Element types 

1 required; must have value representation 
and non-zero length 

1C conditional 1 

2 must be listed but can have zero value and 
zero length 

2c conditional 

3 user defined, optional 

Endian defines the byte ordering 

Little Endian orders the byte sequence with the least 
significant byte first, the most significant last. Big Endian 
orders bytes in the reverse sequence. Endian ordering ap- 
plies only to numbers. Text strings are represented by 
ASCII bytes in the sequence of letters or symbols. 

FDDI fiber-distributed data interface, high-speed network 
(used for infoRAD 1993 demonstration) 

Film session a group of films 

Frame a data packet 



Gateway device and conversion method between heterog- 
enous networks or systems 

HL 7 High Level 7, an ANSI member, dealing with HIS 
development 

IEEE Institute of Electrical and Electronic Engineers 

Instance a representation of a class 

Information objects structures of object-oriented design 

Internet a collection of networks and gateways, including 
ARPnet, NSFnet, MILnet, and others. 

IOD information object definition 

IP Internet Protocol (takes care of addressing and 
makes sure routers know what to do with the data) 

ISO International Standards Organization 

Message a structured data unit for communication. It is di- 
vided into PDUs according to part 8 of the DICOM stan- 
dard ( for network communication ) 

Module a group of data elements 

OSI Open System Interconnection (model developed by 
the ISO) 

Packet structured data sets usually between 1 and 1,500 
characters long 

PAD packet assembler/ disassembler, an X.25 term 

PDU protocol data unit, the transported structure of in- 
formation 



Port computer ports are I/O channels of communication 
(for instance, serial or parallel ports); Internet ports are pro- 
tocol types 

Presentation context consists of abstract syntax and trans- 
fer syntax 

Protocol in OSI terminology, data format for peer-to-peer 
communication 

Routers path switches of computer networks 

Service Class Provider (SCP) a role of an AE corresponds to 
Service Class User (SCU), similar to server and client in net- 
work terminology 

Stack a set of lower OSI layer protocols (for instance, TCP/ 
IP or OSI) 

SMTP simple mail transfer protocol, usually part of TCP/IP 

SOP service-object pair combining command and data infor- 
mation 

SQL structured query language 

TCP transmission control protocol divides the PDUs (pro- 
tocol data units) into sequences of packets and, at the receiv- 
ing end, reassembles these packets into PDUs 

Telnet a terminal emulation program of TCP for remote 
log-in 

Transfer Syntax defines coding (for instance, as big Endian) 

UID unique identifier of information objects and services 

VR value representation, one of the 24 coding methods speci- 
fied in part 5 of the standard 



B. Healthcare 
Informatics 
Standards 
Planning 
Panel 



The Healthcare Informatics Standards Planning Panel 
(HISPP) was formed after a meeting in March 1991 by rep- 
resentatives of the U.S. government, specifically the Food 
and Drug Administration (Dr. M. Greberman), Agency for 
Healthcare Policy and Research (Dr. M. Fitzmaurice ), a 
representative of ANSI, representatives of ACR and 
NEMA, and a representative of Comite Europeen de 
Normalisation (CEN) (European Standards Committee) 
(Dr. G. De Moore of Belgium). Dr. C. McDonald of the Indi- 
ana School of Medicine chaired the meeting. Two topics 
were discussed : 



• Formation of a broad U.S. organization capable of co- 
ordinating the many standarization activities in health 
care. 

• Formation of a group authorized to work with CEN 
TC 251, the technical committee that deals with health 
care informatics, toward "harmonization" of U.S. and 
European health care informatics developments. 

At a later meeting the scope of HISPP was defined as 
comprising : 



1. Health care models and electronic health care 
records; 

2. The interchange of health care data, images, sounds 
and signals within and between organizations and prac- 
tices; 

3. Health care records and terminology; 

4. The communication with diagnostic instruments and 
health care devices; and 

5. Additional areas of concern or interest with regard to 
health care. 



The objective was stated as follows: 
"Coordinating the work of standards group ... toward 
achieving the evolution of a unified set of non-redundant, 
non-conflicting standards that are compatible with ISO 
and non-ISO communication environments." 



Now, 3 years later, a large body of standards-writing or- 
ganizations addresses major isssues such as 

• A computer-based patient record 

• Message communication 

• Code and vocabulary 

• Privacy, security, and confidentiality 

• Provider identification 

The activities of ACR and NEMA, in particular the de- 
velopment of the DICOM standard, fits well into the "Mes- 
sage Communication Task Force" and are indeed seen as an 
important contribution. 

Participating standards-writing organizations are the 
American Dental Association; American Health Informa- 
tion Management Association; ASC X3, which deals with 
databases, file formats, and communication protocols; ASC 
X12N, which deals with insurance; American Society for 
Testing of Materials, which has been active for many years 
in the general area of health care informatics; Health Level 
Seven, which addresses hospital information systems; Insti- 
tute of Electrical and Electronic Engineers with the devel- 
opment of Medical Information Bus and the Medical Data 
Interchange standard; NEMA; and others. 

The HISPI? an ANSI organization, is authorized to rep- 
resent U.S. standard activities vis a vis CEN through its 
membership in ISO. This relationship has facilitated accep- 
tance of the DICOM standard by TC 251 as a basis for the 
European MEDICOM development. The participation of 
European CTN developers in the 1993 infoRAD demon- 
strations was evidence of such acceptance. DICOM repre- 
sentatives and TC 251 representatives have met in the past 
and will continue to meet in the future. The common goal is 
an international standard for health care informatics. 



C. CEN 
Technical 
Committee 251 
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In July 1989, the Senior Officials Group on Information 
Technology Standards of the European Community issued a 
mandate for a study of what is being done and what should 
be done in the field of medical informatics standards. The 
mandate was passed to the European standardization bodies 
CEN, CENELEC, and ETSI, and after consultation with 
the national standards bodies, the work was divided into two 
sections. 

Part A, which is concerned with the informatics issue, 
was assigned to CEN/IT Project team 001, and part B, 
which is concerned with the applications of the open sys- 
tems standard, was assigned to the European Workshop for 
Open Systems (EWOS) Project Team 007. 

In spring of 1990, CEN established Technical Committee 
251 on "Medical Informatics" with representatives from all 
18 member organizations. TC 251 is chaired by Professor 
George de Moore, of Belgium. The two project teams (CEN 
and EWOS ) are working under the guidance of TC 251. 

The two project teams suggested development or adop- 
tion of a set of European standards (EN standards ) and 
agreed on a common taxonomy for the work items. There 
are 48 work items defined in the CEN report and 42 work 
items in the EWOS report. However, some of the work 
items in the two reports are identical. 

Within the scope of applications imaging is possibly the 
most important one. It attracts the attention of a large 
number of people. All proposals to CEN that have to do 
with imaging are based on the ACR-NEMA standard. 

The following is an excerpt of a report of one member of 
WG 4, TC 251, made in November 1990: 



Working Groups of TC 251 

WG 1 Health Care Information Modelling and Medical Record 
WG 2 Health Care Terminology, Semantics and Knowledge 
Bases 

WG 3 Health Care Communication and Messages 
WG 4 Medical Imaging and Multimedia 
WG 5 Medical Devices 

WG 6 Health Care Security, Privacy, Quality and Safety 
WG 7 Intermittently Connected Devices 
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